This API security checklist walks through the practical checks worth making on any API before it goes into production: authentication and authorization, rate limiting, input validation, data exposure, and transport security. None of it requires deep technical expertise, mostly it comes down to configuration choices that are easy to get right and just as easy to overlook. Whether you’re auditing your own API or learning what to look for, work through each section below and tick off what’s already covered. Anything you’re unsure about links to a fuller explanation.
What This API Security Checklist Covers
This checklist draws on the same risk categories laid out in the OWASP API Security Top 10, a widely referenced industry resource, condensed here into five practical categories you can work through directly: authentication and authorization, rate limiting, input validation, data exposure, and transport security.
📌 How to use this: Go category by category. Each checkbox is clickable, so you can check items off as you review them. Use the print button below to save or print a clean copy.
🖨️ Print This Checklist
🔐 Authentication & Authorization
Broken authentication and authorization are consistently the most exploited API weaknesses, mostly because access checks get skipped once a request already looks valid.
- Every endpoint requires authentication unless it is explicitly meant to be public.
- Authorization is checked per object on every request, so changing an ID in the URL can’t pull someone else’s data.
- API keys and tokens are never hardcoded in client-side code or committed to version control. See our guide on dangerous password practices.
🚦 Rate Limiting & Resource Consumption
Without limits, a single client can exhaust resources meant for everyone else, whether by accident or on purpose.
- Rate limiting is enforced per user, IP, or API key on every endpoint.
- List and search endpoints enforce pagination rather than returning unlimited records in one request.
🧹 Input Validation
Client-side validation is a convenience, not a defense. Every input needs a server-side check regardless of where the request came from.
- All input is validated and sanitized server-side, not just in the client application. See our breakdown of user input validation.
- File upload endpoints restrict file type, size, and content, not just the file extension. Related: unrestricted file upload vulnerability.
📤 Data Exposure
Returning more data than a client needs is one of the easiest mistakes to make, and one of the easiest to miss during testing.
- Responses only include the fields the client actually needs, not full internal objects.
- Error messages do not leak stack traces, internal file paths, or database details.
🌐 Transport & Configuration
The API itself can be well designed and still be exposed by how it’s deployed, which is why understanding how firewalls fit into API security is part of the complete picture.
- Every endpoint enforces HTTPS, with no fallback to plain HTTP.
- Certificate validation is properly enforced rather than skipped or overridden in code. See dangerous SSL validation mistakes.
- CORS is configured to allow only trusted origins, not a wildcard.
None of these checks require deep security expertise. Most are configuration decisions made once, early in development, and then quietly forgotten as the API evolves and new endpoints get added. Working through this list before any major release, or once a year as a matter of habit, catches drift before it turns into a real vulnerability worth worrying about.
This checklist pairs well with our deeper guides on API security. Explore the full API Security hub for more.