How to use API-Security-Checklist: a practical guide

What the checklist is and what it is not

The project is a single README file organised into stages: Authentication, Access, Authorization, Input, Processing, Output, CI & CD, and Monitoring. Each item is a short recommendation, such as using standard authentication instead of Basic Auth or sending a nosniff header.

It does not scan anything. The README describes a list of items to check, not a tool that tests your API. It also does not explain each attack in depth, so you will need other resources when you want background.

• Type: a markdown checklist you read and work through
• Licence: MIT
• Install: none; you can read it online or clone the repository
• Prerequisites: none listed

Get a copy of the checklist

You can read the README directly on GitHub. If you want a local copy to annotate or to keep in your team's repository, clone it with the command from the project's README.

• Read it online on the project's GitHub page
• Clone it to keep a local copy you can edit

Work through the checklist before launch

Go through each section against your API design and implementation. Mark each item as done, not applicable, or needs work. The items are phrased as checkboxes, so a markdown view with task lists makes this easy to track.

Start with Authentication and Authorization, since many items there cover how users and applications prove who they are. Then move to Input and Output, which cover what your API accepts and what it returns.

• Authentication: avoid Basic Auth, use standard authentication, limit login retries
• Access: throttle requests, use HTTPS with TLS 1.2+, turn off directory listings
• Authorization: validate redirect_uri, avoid response_type=token, use a state parameter
• Input: use the right HTTP method, validate content types, keep credentials out of URLs
• Output: set security headers, remove fingerprinting headers, avoid detailed error messages
• CI & CD: run tests, require code review, check dependencies for known vulnerabilities, plan rollbacks
• Monitoring: centralise logs, avoid logging sensitive data, use an IDS or IPS

Use it in code reviews

Because each item is a short, specific statement, the checklist works as a reference during code review. A reviewer can check whether a pull request sets the expected headers, validates input types, or keeps secrets out of URLs.

Some items are phrased as design rules, such as using UUIDs instead of auto-incrementing IDs or using /me/orders instead of /user/654321/orders. These are easy to check in an API specification before any code is written.

• Add the items relevant to your stack to your team's review template
• Link specific items in review comments so the reason is clear
• Note items that do not apply to your API, such as GraphQL-specific items if you do not use GraphQL

Audit an existing API

To audit a running API, pick the items you can verify from outside, such as which headers the responses send, whether directory listings are off, and whether error messages reveal internal details. Items about CI/CD and monitoring need access to your pipeline and logs.

The checklist does not tell you how to test each item. For that, you will need your own tests or other tools.

• Check response headers for X-Content-Type-Options, X-Frame-Options and Content-Security-Policy
• Check whether X-Powered-By or Server headers are exposed
• Check that error responses are generic

Use the advanced section for newer patterns

The README ends with an advanced section covering rate limiting and abuse prevention, GraphQL-specific security, secrets management, and zero trust architecture. These items are phrased the same way as the main list.

The README also suggests that you may not need JWT and can use a randomly generated API key. It links to an external article on alternatives to JWT for cases that need asymmetric encryption or tamper prevention.

• Rate limiting and abuse prevention
• GraphQL-specific security
• Secrets management
• Zero trust architecture