shieldfy/API-Security-Checklist: sixty API security items you can read in one sitting

A repository that contains only Markdown, in thirty languages

The description is precise about scope: a checklist of the most important security countermeasures when designing, testing and releasing an API. The repository itself backs that up by containing nothing else. The file tree is `CONTRIBUTING.md`, `LICENSE`, and thirty translated copies of `README.md`, from Arabic through Azerbaijani, Bengali and Catalan to Traditional Chinese. There is no source directory, no build, no package manifest, and no published language field, because there is no program here to describe.

That makes installation a non-question, and it is worth saying so plainly rather than inventing a build step. The default branch is `master`, the license is MIT, the repository is not archived, and the last push was on 2026-07-21. It publishes no GitHub releases, so there is no version history to track and no upgrade path to plan around. Versioning, if you want it, has to come from your own fork.

The structure inside a single README is where the real design lives. Eight core headings cover Authentication, Access, Authorization, Input, Processing, Output, CI and CD, and Monitoring. Authorization carries one sub-heading, OAuth. After the horizontal rule that closes those, a section titled API Security Best Practices (Advanced) opens with Rate Limiting and Abuse Prevention, GraphQL-Specific Security, and Secrets Management. So the checklist has two layers: a stable core a team can standardize on, and an extension that reads more like notes appended over time.

The four authentication and access items people skip first

The Authentication group is short, which is itself informative. It has four items: do not use Basic Auth, do not reinvent token generation or password storage, use Max Retry and jail features in Login, and encrypt all sensitive data. The second item is the load-bearing one. It is a refusal to write custom cryptography, and it is aimed at the case where an API has an accounts table and someone is tempted to hand-roll a token format.

Access adds the network-level controls: throttle requests against DDoS and brute force, require HTTPS with TLS 1.2 and secure ciphers, make sure the `Host` header matches SNI, send HSTS to blunt SSL stripping, turn off directory listings, and for private APIs allow access only from safelisted IPs and hosts. The SNI point is the one most hand-rolled proxies get wrong, because it only matters when a single address terminates connections for more than one hostname.

Two of those items push work outward to infrastructure rather than into application code. Rate limiting and IP safelisting are properties of a gateway, a reverse proxy or a network policy, and the checklist says as much later on, when it recommends an API Gateway for caching and Rate Limit policies such as Quota, Spike Arrest, or Concurrent Rate Limit. Read together, the advice is: enforce these at the edge, and do not spend application code on them.

OAuth rules that prevent the two classic redirect attacks

The OAuth subsection has four items, and they read like a direct response to specific incidents rather than general guidance. Always validate `redirect_uri` server side to allow only safelisted URLs. Always exchange for a code rather than a token, meaning `response_type=token` should not be allowed. Use a `state` parameter carrying a random hash to prevent CSRF in the authorization flow. Define a default scope, and validate scope parameters for each application.

The first two close the same hole from different directions. An open redirect lets an attacker point your authorization server at a page they control. The implicit flow, where the token comes back in the URL fragment, means the token can leak through referrers, browser history and logs. Either one, if unaddressed, hands a stranger someone else's session. The scope item is the quieter version of the same problem: a client that is only approved for read access should fail loudly when it asks for write.

The Input group is the longest section in the checklist, and it mixes semantics with validation in a way that is easy to skim past. Map methods to operations (`GET` reads, `POST` creates, `PUT` and `PATCH` update, `DELETE` removes) and answer `405 Method Not Allowed` when they do not. Check the `Accept` header for content negotiation and answer `406 Not Acceptable` on a mismatch. Validate the `content-type` of posted data as you accept it. Validate user input against XSS, SQL injection and remote code execution. Keep credentials, passwords, security tokens and API keys out of URLs, and use the standard Authorization header instead. Encrypt on the server side only.

Output headers and the deliberate vagueness of error messages

The Output group is eight items and reads like a checklist derived from a header audit. Send `X-Content-Type-Options: nosniff`. Send `X-Frame-Options: deny`. Send `Content-Security-Policy: default-src 'none'`. Remove fingerprinting headers, naming `X-Powered-By`, `Server` and `X-AspNet-Version` as examples. Force the response `content-type` to match what you actually return. Do not return credentials, passwords or security tokens. Return the status code that matches the operation, with `200 OK`, `400 Bad Request`, `401 Unauthorized` and `405 Method Not Allowed` given as examples.

Then there is the item with the most leverage per word: do not return overly specific error messages that reveal implementation details, use generic messages instead and log the detailed information only on the server side. Stack traces, SQL fragments and driver names in a 500 response hand an attacker a map of your stack, and the fix costs nothing but a log statement.

The Processing group adds nine more, several of which are about identifiers and parsers rather than headers. Check that every endpoint sits behind authentication. Avoid user-owned resource IDs in the path, preferring `/me/orders` over `/user/654321/orders`. Do not auto-increment IDs, use `UUID`. If you parse XML, keep entity parsing disabled to avoid XXE, and keep entity expansion disabled for XML, YAML or anything else with anchors and refs, to avoid a Billion Laughs style bomb. Use a CDN for file uploads. Move large work to Workers and Queues so the response returns fast. Turn DEBUG mode off. Prefer non-executable stacks when they are available.

The identifier advice interacts. Sequential IDs let one customer enumerate another's orders; opaque UUIDs remove that, which is why the two items sit together.

Pipelines and monitoring treated as security surfaces

The CI and CD group has six items. Audit design and implementation with unit and integration test coverage. Use a code review process and disregard self-approval, which is aimed squarely at repositories where one person merges their own change. Statically scan every component before pushing to production, including vendor libraries and other dependencies. Continuously run static and dynamic analysis. Check dependencies, both software and operating system, for known vulnerabilities. Design a rollback solution for deployments.

The rollback item is the one most teams skip and the one that matters most on the day something is wrong. A pipeline that can promote but not reverse turns a bad deploy into an incident with a clock on it.

Monitoring is five items, and it is the only group that names specific tools rather than headers or protocols. Use centralized logins for all services and components. Use agents to monitor traffic, errors, requests and responses. Use alerts through SMS, Slack, Email, Telegram, Kibana or Cloudwatch. Ensure you are not logging sensitive data such as credit cards, passwords or PINs. Use an IDS or IPS system to monitor API requests and instances. That second to last item is the one to watch: centralized logging is only safe if the fields you centralize have been reviewed first, because payment data and credentials tend to ride along inside otherwise unremarkable request bodies.

The repository disagrees with its own JWT tag

The See also section is short and pointed. It links a collection of useful resources for building RESTful HTTP and JSON APIs, and then adds: you do not need JWT, just use a randomly generated API key, with a link to alternatives to JWT for anyone who needs asymmetric encryption or tamper prevention. The repository's own topics include `jwt` and `oauth2`, so it is tagged with the mechanism its closing note questions. Both facts sit in the same place, and the honest reading is that the checklist is agnostic about token format and only firm about not hand-rolling one.

That is a real editorial position rather than an oversight, and it is the most interesting thing in a document that is otherwise a list. Every other item asks for a specific control; this one asks you to pick a category of solution deliberately.

It is also where the gap between the project and its audience shows. Searches for this project pair it with OWASP, and with requests for a PDF or an Excel version. The repository supplies neither a mapping to OWASP API Security Top 10 nor any export format: thirty one Markdown files and a CONTRIBUTING guide. For a team that wants a printable standard or a control that maps to a compliance clause, the fork has to start immediately. For a team that wants sixty sentences to argue about during a design review, the README is already the right size, and MIT licensing means every translation in the tree is fair game to adapt.

Editorial conclusion

This repository works best as a review prompt, not a specification. It is fast to read end to end, its items are concrete enough to argue about, and its MIT license means a team can fork it into an internal standard without asking. What it cannot do is tell you which of the sixty items apply to your architecture, because nothing in it is mapped to a threat model or to OWASP API Security Top 10, and the searches people run for this project are mostly looking for the same list in a spreadsheet. Start by marking which items your current gateway and framework already handle, then treat the unmarked ones as a to-do list with owners. The single most quotable line in it is also the one most teams will skip: do not return overly specific error messages to the client, log the detail server side instead.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. shieldfy/API-Security-Checklist on GitHub