Most API breaches come from checks nobody ran: an endpoint that never verified the caller owned the record, a forgotten version still live, or a client that could pull millions of rows without tripping an alert. This template is a tickable checklist that follows an API through its life, from design and build to deployment, runtime and retirement, with every check mapped to the OWASP API Security Top 10 2023 and, where one exists, an OWASP ASVS 5.0 requirement you can quote in a ticket. It covers REST, GraphQL and WebSocket APIs, internal and public, and the machine credentials that call them. It is written for API owners, application security engineers, platform teams and testers. For why each risk matters and how the controls work, read the API Security Guide; this page is the list you check against.
How to use this template
Copy the checklist per API (or per API product) and replace text in square brackets, such as [API name], [gateway] and [SIEM], with your own details.
Each check carries a reference: API1 to API10 are the OWASP API Security Top 10 2023 risks; V numbers are OWASP ASVS 5.0 requirements. Use them in tickets and test cases so findings are traceable.
Mark each line Pass, Fail, Partial or Not applicable, and record the evidence (a test result, gateway config export, pull request or screenshot) beside it. A check without evidence counts as Fail at review.
Run sections 2 and 3 at design and code review, sections 4 and 5 before every production release, and sections 6 and 7 at least [quarterly] and after any incident.
Values in brackets, such as [10 minutes], are illustrative starting points, not requirements from any standard, except where a reference says otherwise.
Data classification of the most sensitive field returned
[Restricted / Confidential / Internal]
Named owner (team and person)
[Team, name]
Callers (human apps, partners, workloads, AI agents)
[List]
Specification location
[Repository path to OpenAPI or GraphQL schema]
Review date, reviewer, result
[Date], [Name], [Pass / Pass with findings / Fail]
2. Design checks
#
Check
Reference
Result and evidence
2.1
The API is registered in [API inventory] with owner, environment (production, staging, test), audience (public, partner, internal) and version.
API9
[ ]
2.2
A machine-readable specification (OpenAPI or GraphQL schema) exists, is version-controlled and is generated or validated in CI. See the OpenAPI Specification Security Guide.
API9
[ ]
2.3
A threat model covers each data flow and trust boundary, including integrated third-party APIs. See the Threat Modelling Guide.
API10
[ ]
2.4
Authorisation rules are documented for every function (who may call it) and every data item (whose records they may touch), including field-level read and write rules.
API1, API3, API5; V8.1.1, V8.1.2
[ ]
2.5
Sensitive business flows (sign-up, purchase, booking, referral credit, password reset, OTP validation) are listed with the abuse each could suffer and the intended limit.
API6
[ ]
2.6
Each caller type has a defined authentication method: user tokens via OAuth 2.0 or OpenID Connect for user context, workload credentials (mTLS, private_key_jwt, workload identity) for services; API keys identify client applications only, never users.
API2
[ ]
2.7
Object identifiers exposed to clients are random and unpredictable (for example UUIDs); this supplements, never replaces, per-object authorisation.
API1
[ ]
2.8
Response schemas return only the fields each operation needs; no generic serialisation of whole objects.
API3
[ ]
2.9
A deprecation and sunset plan exists for each version, with a date by which old versions are removed or given the same protection as the current one.
Every operation that takes an object ID from the client checks that the authenticated caller may perform that action on that specific record, in the data access layer or a central policy service.
API1; V8.2.2
[ ]
3.2
Function-level access is deny by default; administrative operations require an explicit role, enforced centrally rather than per controller.
API5; V8.2.1
[ ]
3.3
Mass assignment is blocked: only an allow list of properties can be written by each operation (for example, a user cannot set role or isAdmin).
API3
[ ]
3.4
Tokens are validated on every request: signature with an allow-listed algorithm (never none), issuer, expiry (exp, nbf), token type and audience (aud) matching this API. See the JWT Security Guide.
API2; V9.2.1 to V9.2.3
[ ]
3.5
Scopes or permissions in the token are checked per operation; a token issued for one API or scope is rejected by another.
API5; V10.4.11
[ ]
3.6
Password reset, credential recovery and OTP endpoints have brute-force protection at least as strict as login, and sensitive account changes (email, phone, MFA device) require re-authentication.
API2
[ ]
3.7
Workload and partner callers each have their own credential, scoped to the operations they need, stored in a secrets manager and with an expiry or rotation date. See the API Key Management Guide.
API2, API5
[ ]
3.8
For high-value APIs, access tokens are sender-constrained (mTLS certificate-bound tokens, RFC 8705, or DPoP, RFC 9449) so a stolen token cannot be replayed from elsewhere. See the mTLS Guide.
API2; V10.4.14
[ ]
3.9
Automated tests prove that user A cannot read or change user B's objects and that a non-admin token is refused on every admin route; the build fails if these tests fail.
API1, API5
[ ]
4. Build checks: input, output and resource limits
#
Check
Reference
Result and evidence
4.1
Requests are validated against the schema: types, string lengths, array sizes, numeric ranges and upload size, rejecting unknown fields. See the Input Validation and Output Encoding Guide.
API4, API8
[ ]
4.2
Page size and record-count parameters have a server-side maximum of [100] items; the client cannot request unbounded results.
API4
[ ]
4.3
Only the content types the API needs are accepted (for example application/json); others return 415. Every response carries a Content-Type that matches its body.
API8; V4.1.1
[ ]
4.4
Only supported HTTP methods are enabled per route; others are rejected.
API8; V4.1.4
[ ]
4.5
Error responses follow a fixed schema and never include stack traces, SQL, internal hostnames or framework versions.
API8
[ ]
4.6
GraphQL: depth limit, amount limit, query cost analysis or a persisted-query allow list is enforced, and introspection is disabled in production unless the API is meant for external developers. See the GraphQL Security Guide.
API4; V4.3.1, V4.3.2
[ ]
4.7
Any feature that fetches a URL supplied by the client uses an allow list of hosts, schemes and ports, disables redirects, uses a maintained URL parser and cannot reach internal ranges or cloud metadata endpoints. See the SSRF Prevention Guide.
API7
[ ]
4.8
Data received from third-party APIs is validated and sanitised before use, over TLS, and redirects from them are followed only to allow-listed locations.
API10
[ ]
4.9
WebSockets use wss:// only and the handshake checks the Origin header against an allow list.
API8; V4.4.1, V4.4.2
[ ]
5. Deployment and configuration checks
#
Check
Reference
Result and evidence
5.1
All traffic, including internal service-to-service calls, uses TLS 1.2 or higher; non-browser API endpoints do not silently redirect HTTP to HTTPS but refuse plain HTTP.
API8; V4.1.2
[ ]
5.2
Rate limits are set per client and per operation at [gateway], with stricter limits on authentication, OTP and recovery endpoints; exceeding them returns 429.
API4, API2
[ ]
5.3
Container or function limits for memory, CPU, timeouts and concurrency are set, and spending limits or billing alerts exist for paid downstream services (SMS, email, AI model APIs).
API4
[ ]
5.4
Browser-facing APIs have an explicit CORS allow list (no reflected Origin with credentials) and appropriate security headers. See the CORS Misconfiguration Guide.
API8
[ ]
5.5
Headers set by intermediaries (for example X-Forwarded-For) cannot be overridden by clients, and all servers in the chain parse request boundaries the same way to prevent desync.
API8; V4.1.3, V4.2.1
[ ]
5.6
Debug endpoints, sample routes, admin consoles and API documentation are not exposed publicly unless intended; documentation is available only to authorised users.
API8, API9
[ ]
5.7
Non-production deployments do not use production data, or receive the same protection as production if they must.
API9
[ ]
5.8
Every exposed version, not only the current one, sits behind the same gateway, WAF and monitoring. See the API Gateway Security Guide.
API9
[ ]
5.9
Credentials used by the API to reach databases and downstream services come from a secrets manager or workload identity, never from source code, images or plain environment files.
API8
[ ]
6. Runtime and monitoring checks
#
Check
Reference
Result and evidence
6.1
All authentication attempts, success and failure, are logged with caller identity, client ID and source.
API2; V16.3.1
[ ]
6.2
Failed authorisation decisions (403s) are logged and alert when one client produces [more than 50 in 5 minutes] or walks sequential object IDs.
API1, API5; V16.3.2
[ ]
6.3
Records returned per client per hour are baselined, with an alert at [3x] the baseline, so bulk harvesting is caught in hours, not weeks.
Gateway and application logs reach [SIEM] within [5 minutes] and are retained for [12 months].
API9
[ ]
6.6
Traffic to hosts and paths missing from the inventory (shadow or zombie APIs) is detected from gateway, load balancer or DNS data and reported to the owner.
API9
[ ]
6.7
Automated abuse of sensitive flows is detected, for example add-to-cart and purchase within one second, or many accounts from one device.
API6; V2.4.1, V2.4.2
[ ]
7. Testing, change and retirement checks
#
Check
Reference
Result and evidence
7.1
Authenticated dynamic testing with at least two user roles and two tenants runs before each major release, covering object-level and function-level authorisation. See the API Penetration Testing Guide.
API1, API3, API5
[ ]
7.2
An independent API penetration test has run in the last [12 months] for public and partner APIs, and findings above [medium] are closed or accepted by the owner.
All
[ ]
7.3
Dependencies, base images and the gateway are scanned and patched under the vulnerability management SLA.
API8
[ ]
7.4
When a new version fixes a security flaw, a risk decision is recorded for older versions: backport the fix or force clients to migrate by [date].
API9
[ ]
7.5
Retired versions return 410 or are removed at the gateway, their DNS records and credentials are deleted, and the inventory is updated.
API9
[ ]
7.6
Third-party APIs the service consumes have been assessed for their security posture before integration and are re-reviewed [annually].
API10
[ ]
8. Coverage map and sign-off
Use this table to confirm that every OWASP API Top 10 2023 risk has at least one passing check before sign-off.
Sign-off: API owner [name, date] · Application security [name, date] · Open findings with owner and due date: [list].
Implementation guidance
Start with inventory. You cannot check APIs you do not know about. Reconcile the inventory against gateway routes, load balancer listeners and DNS before the first review; the hosts that appear in traffic but not in the register are usually the riskiest.
Prioritise by exposure and data. Run the full checklist first on public and partner APIs that return Restricted or Confidential data, then internal APIs. A small team with a handful of APIs can review them all in one cycle; a large estate should tier APIs and automate sections 4 to 6 through gateway policy and CI.
Automate what you can. Schema validation, method restrictions, TLS, rate limits and log forwarding belong in gateway policy and CI linting of the specification, so they fail the build rather than the review. Authorisation checks (3.1, 3.2) cannot be fully automated by a gateway because they depend on business data: they need code-level tests.
Test safely. Introduce new gateway limits in log-only or monitor mode for [two weeks], compare against real traffic, then enforce. Keep the previous gateway configuration versioned so a limit that blocks legitimate clients can be rolled back in minutes.
Measure. Track the share of APIs in the inventory with a named owner and a specification (target 100 percent), the share of public APIs passing all section 3 checks, the number of undocumented hosts found per month, mean time to close high findings, and the time from first anomalous bulk retrieval to alert.
Learn from incidents. The T-Mobile API Breach 2023 ran for about six weeks before detection while an API returned data on around 37 million accounts; checks 2.1, 3.1 and 6.3 exist to stop exactly that combination of unknown exposure, weak authorisation and no volume alerting.
NHIMG Editorial Note
Researched and written by the NHI Mgmt Group editorial team using AI tools, under the editorial direction of Lalit Choda. Facts are drawn from the sources listed on this page and checked by our automated quality process. Last updated 8 November 2026. Spotted an error? Use our contact page.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM and Agentic AI security.
nhimg.org
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.