API Security Testing Checklist: OWASP Top 10 Mapped (CSV)
Quick answer
An API security testing checklist lists the checks to run against every API before release, grouped by the OWASP API Top 10 (2023): object and function authorization, authentication and JWT, OAuth, rate limiting, data exposure, SSRF, misconfiguration, inventory, unsafe upstream calls and logging. Use the 76-item CSV below, automate what you can in CI and test the rest by hand.
Reviewed by Smeet Gohel
Part of the API Security & Auth Testing hub. Start with the pillar guide: API security testing: the complete guide.
This API security testing checklist gives you 76 checks to run against an API before every release. They are grouped by the OWASP API Security Top 10 (2023), and each comes with a concrete way to test it and the result you should expect. Download the full checklist as CSV to import into a spreadsheet, GitHub issues or your test management tool.
The checklist is the practical companion to our API security testing guide, which explains the methods and tools. For a deeper walkthrough of each OWASP risk with attack examples, see OWASP API Top 10 vulnerabilities and how to test them.
How to use this API security testing checklist
- Download the CSV and filter it to the areas your API has. A public read-only API won't need the OAuth or business-flow rows; a payments API needs all of them.
- Set up two test users (and a third with admin rights) in a non-production environment. The most important authorization checks compare what one user can do with another user's data.
- Start with the Critical rows. Broken authorization and authentication hold the top two places in the OWASP list, and they are easy to test once you have two users.
- Mark each row as pass, fail, not applicable or not tested. "Not tested" is a valid answer; a blank is not.
- Automate the rows marked "Yes" and run them in CI. Keep the "Partly" rows on a manual release checklist.
- Re-run on change. New endpoints, auth changes and new upstream integrations all reopen rows.
Every check assumes you test against an environment you own or are authorized to test. Never run burst, injection or data-changing checks against production without explicit approval.
OWASP API Security Top 10 (2023) checklist
This table maps each 2023 risk to the checks in the CSV and gives the test ideas that find most real issues.
| Risk | What goes wrong | Test ideas | CSV rows |
|---|---|---|---|
| API1 Broken Object Level Authorization | A user reads or changes another user's object by changing an ID | Create an object as user A, request it with user B's token; try neighbouring and random IDs; repeat for update and delete; check tenant isolation | AUTHZ-01 to 04 |
| API2 Broken Authentication | Weak or missing checks on credentials, tokens and sessions | No token, malformed token, expired token; JWT alg: none, stripped signature, algorithm confusion; brute-force limits; logout revokes tokens | AUTH-01 to 09, JWT-01 to 07, OAUTH-01 to 04, 06, 07 |
| API3 Broken Object Property Level Authorization | Too many fields returned, or fields a user shouldn't set are writable | Send role, isAdmin, ownerId in a PATCH; compare response fields with the schema per role; scan for secrets | AUTHZ-05, 06, JWT-08, DATA-01 to 03 |
| API4 Unrestricted Resource Consumption | No limits on rate, size or cost of requests | Burst above the limit and expect 429; spoof X-Forwarded-For; huge pageSize; oversized body; GraphQL depth and aliases | RATE-01 to 03, 05 to 08 |
| API5 Broken Function Level Authorization | A normal user calls admin or management functions | Call admin routes with a user token and with no token; try undocumented methods; check scopes per operation | AUTHZ-07, 08, OAUTH-05 |
| API6 Unrestricted Access to Sensitive Business Flows | Automated abuse of flows like checkout, sign-up or coupon redemption | Replay one-time requests; send 5–10 in parallel; skip or reorder steps; tamper with values between steps; tighter limits on login and OTP | FLOW-01 to 04, RATE-04 |
| API7 Server Side Request Forgery | The API fetches a URL the attacker controls, reaching internal systems | Submit metadata IPs (169.254.169.254), loopback, private ranges and encoded variants in URL fields; follow redirects | SSRF-01 to 03 |
| API8 Security Misconfiguration | Missing hardening: TLS, headers, CORS, verbose errors, exposed consoles | Check TLS and HSTS; nosniff and no-store; reflected CORS origins; stack traces; /actuator, /debug, /.git | CONF-01 to 07, DATA-04 |
| API9 Improper Inventory Management | Old versions, undocumented endpoints or staging hosts left exposed | Call retired versions; diff gateway routes against the spec; probe non-production hosts from outside | INV-01 to 03 |
| API10 Unsafe Consumption of APIs | Your API trusts data from third-party APIs too much | Mock the upstream to return malformed, oversized or redirecting responses; check TLS and timeouts on outbound calls | UC-01 to 03 |
| Injection (outside the 2023 list) | SQL, NoSQL, command, XXE, path traversal | Payloads in every parameter and body field; watch for errors, delays and behaviour changes | INJ-01 to 06 |
| Logging and monitoring (cross-cutting) | Attacks go unnoticed, or logs leak secrets | Check failed auth and authz are logged; search logs for tokens; trigger an alert | LOG-01 to 06 |
Injection moved out of the API Top 10 in 2023 (it was API8 in 2019). It still belongs on any checklist, and fuzzing is the fastest way to cover it; see API fuzz testing.
Run these checks on every build. Shift-Left API's API security testing add-on (paid; included on Trial) runs 94 of its 100 catalogue checks on a standard install. Each one is mapped to the OWASP API Security Top 10 (2023), OWASP ASVS 5.0 and CWE. Eight authorization checks use a second test user. Every report opens with what was not checked, and a probe that couldn't reach your API counts as "not evaluated", never as a pass. Start a free trial to try it on a non-production environment.
Ready to shift left with your API testing?
Try our no-code API test automation platform free. Generate tests from OpenAPI, run in CI/CD, and scale quality.
Authentication, JWT and OAuth checks
Authentication flaws are the second-ranked risk and the easiest to test thoroughly, because each check is a single request with a modified credential. For step-by-step code, see the JWT testing guide and OAuth API testing best practices.
| ID | Check | How to test | Expected |
|---|---|---|---|
| AUTH-01 | Protected endpoints require credentials | Call each protected operation with no Authorization header | 401 |
| AUTH-03 | Expired tokens are rejected | Use a token whose exp is in the past | 401 |
| AUTH-04 | Brute force is limited | Repeated failed logins against a throwaway account | 429 or lockout at the documented threshold |
| AUTH-05 | No username enumeration | Compare unknown user vs wrong password | Same status, body and similar timing |
| AUTH-06 | No credentials in URLs | Look for tokens or keys in query strings | Headers or body only |
| AUTH-07 | Logout revokes tokens | Reuse the access and refresh tokens after logout | 401 |
| JWT-01 | alg: none rejected | Re-encode a token with "alg":"none" and no signature | 401 |
| JWT-02 | Signature verified | Change sub or role, keep the old signature | 401 |
| JWT-03 | Algorithm confusion blocked | For RS256, sign with HS256 using the public key as the secret | 401 |
| JWT-04 | iss and aud validated | Validly signed token for another issuer or audience | 401 |
| OAUTH-01 | PKCE with S256 required | Authorization request without code_challenge, or with plain | Refused |
| OAUTH-02 | Exact redirect URI match | Change path, add a subdomain or query parameter | Refused |
| OAUTH-03 | Implicit and password grants off | response_type=token, grant_type=password | Refused |
| OAUTH-06 | Refresh token rotation | Use one refresh token twice | Second use refused |
These follow the current guidance: RFC 8725 (JWT best current practices) and RFC 9700 (OAuth 2.0 security best current practice). RFC 9700 says to use PKCE, exact redirect URI matching, and no implicit or resource-owner password grants.
Rate limiting and resource consumption checks
Missing limits turn your API into a free resource for scrapers, credential stuffers and anyone who wants to run up your cloud bill.
| ID | Check | How to test | Expected |
|---|---|---|---|
| RATE-01 | Per-client limit enforced | Burst above the documented limit | 429 with Retry-After |
| RATE-02 | No bypass by spoofed headers | Repeat the burst rotating X-Forwarded-For, X-Real-IP | Still 429 |
| RATE-03 | Keyed per identity | Two tokens on one IP; one token on two IPs | Each identity limited |
| RATE-04 | Tighter limits on sensitive flows | Burst login, reset, OTP, checkout | Stricter than general limits |
| RATE-05 | Page size capped | ?limit=100000, ?pageSize=-1 | Capped or 400 |
| RATE-06 | Body size capped | Body above the documented maximum | 413, no 500 |
| RATE-07 | GraphQL cost limited | Deep nesting, many aliases, batched queries | Refused with a clear error |
429 Too Many Requests is defined in RFC 6585. For test code and tooling, see testing API rate limiting and throttling.
Data exposure and configuration checks
Many API leaks don't need an attack at all: the data is in the response, and the client simply doesn't display it.
| ID | Check | How to test | Expected |
|---|---|---|---|
| AUTHZ-05 | Mass assignment blocked | Send role, isAdmin, price in POST/PATCH | Ignored or 400; unchanged on read-back |
| AUTHZ-06 | Only documented fields returned | Compare responses with the schema, per role | No internal or extra fields |
| DATA-01 | No secrets in responses | Scan bodies for keys, tokens, hashes, card numbers | None |
| DATA-02 | No personal data to anonymous callers | Call public endpoints | No emails, phones, addresses |
| DATA-04 | Sensitive responses not cached | Check Cache-Control on account data | no-store |
| CONF-01 | TLS enforced | TLS version, certificate, HSTS | TLS 1.2+, valid, HSTS set |
| CONF-03 | CORS not reflecting origins | Origin: https://evil.example with credentials | Not reflected |
| CONF-04 | Errors don't leak internals | Trigger 400, 404, 500 | No stack traces, SQL or paths |
| CONF-06 | No public debug surfaces | /actuator, /debug, /metrics, /.git | 404 or auth required |
The fastest way to catch over-sharing is to validate every response against the response schema with additionalProperties: false, per role. A field that isn't documented shouldn't be there.
Free ZIP: CSV pack + guide
OWASP API Top 10 Test-Case Pack
60 API security test cases mapped to the OWASP API Security Top 10 (2023): positive and negative cases for BOLA, broken auth, SSRF and misconfiguration.
Download FreeLogging, monitoring and inventory checks
You can't respond to attacks you can't see, and you can't protect endpoints you don't know exist.
| ID | Check | How to test | Expected |
|---|---|---|---|
| LOG-01 | Authentication failures logged | Fail logins and token checks, inspect logs | Logged with time, client and reason |
| LOG-02 | Authorization failures logged | Trigger 403s from the AUTHZ checks | Logged with user, resource, action |
| LOG-03 | Secrets never logged | Search logs after a test run for tokens and passwords | None found |
| LOG-04 | Log injection neutralised | CRLF and fake log lines in input fields | Logged as data |
| LOG-05 | Attacks raise alerts | Auth-failure spike in staging | Alert reaches on-call |
| INV-01 | Retired versions off | Call /v1 and other retired versions | 404 or 410 |
| INV-02 | No shadow endpoints | Diff gateway routes or traffic against the spec | Every live route documented |
| INV-03 | Non-production hosts protected | Reach staging and preview hosts from outside | Unreachable or authenticated |
The OWASP Logging Cheat Sheet lists which events to log and which data never to log.
Automating the checklist in CI
About 60 of the 76 rows can run unattended. A practical split:
| Stage | Rows | Why |
|---|---|---|
| Every pull request | AUTH-01 to 03, JWT-01 to 04, AUTHZ-01, 02, 05 to 07 on changed endpoints | Fast, single-request checks that catch the most common regressions |
| Nightly on staging | All "Yes" rows, including rate-limit bursts and injection | Slower or noisier checks that need a stable environment |
| Release checklist (manual) | OAUTH-02, 04, SSRF-03, LOG-05, INV-03 and the business-flow rows | Need judgement, a callback server or a person watching alerts |
| Yearly or before major launches | Everything, as a penetration test | Depth, chaining and business-logic abuse |
Two practices keep the gate trusted:
- Fail on new findings, not on all findings. Baseline known, accepted issues with an owner and an expiry date, and block only regressions and new high or critical findings.
- Export results in a format CI understands, such as SARIF or JUnit, so findings appear in the pull request rather than in a report nobody opens.
API security testing checklist FAQ
What should an API security testing checklist include?
At minimum, checks for every OWASP API Security Top 10 (2023) risk: object level authorization, authentication, property level authorization, resource consumption, function level authorization, sensitive business flows, SSRF, misconfiguration, inventory and unsafe consumption of upstream APIs. Add injection, transport security and logging checks, which the 2023 list covers only partly or not at all.
Is there an API security testing checklist on GitHub?
Several community checklists live on GitHub, and OWASP publishes the API Security Top 10 and the Web Security Testing Guide there too. The CSV on this page is free to download and import into GitHub issues, a spreadsheet or a test management tool; each row has an ID, the OWASP mapping, how to test and the expected result.
How is an API penetration testing checklist different?
A security testing checklist is meant to run on every release, mostly automated, against a test environment. A penetration testing checklist guides a time-boxed, usually manual assessment that also chains findings, explores business logic and judges real-world impact. Most items overlap; the pen test goes deeper on fewer targets.
How often should we run API security tests?
Run automated checks on every pull request for changed endpoints and a full scan nightly or weekly against staging. Repeat manual checks such as OAuth redirect handling and business-flow abuse when those flows change, and commission a penetration test at least yearly or before a major launch.
Which API security checks can be automated?
Most of them: missing and invalid credentials, expired and tampered JWTs, two-user object authorization, admin endpoints with a normal token, rate-limit bursts, page and body size limits, security headers, CORS, error leakage, secrets in responses and retired versions. OAuth redirect handling, SSRF via redirects and alerting usually need some manual work or extra tooling.
Sources and further reading
- OWASP API Security Top 10 (2023): the risk categories this checklist is mapped to.
- OWASP Application Security Verification Standard (ASVS): detailed verification requirements.
- OWASP Web Security Testing Guide: test procedures for authentication, sessions and input handling.
- RFC 8725: JSON Web Token Best Current Practices and RFC 7519: JWT.
- RFC 9700: Best Current Practice for OAuth 2.0 Security and RFC 7636: PKCE.
- RFC 6585: Additional HTTP Status Codes (429).
- OWASP Logging Cheat Sheet and OWASP SSRF Prevention Cheat Sheet.
- Download the API security testing checklist (CSV, 76 checks)
Ready to shift left with your API testing?
Import your OpenAPI spec and get a runnable test suite, in our cloud or on your own infrastructure.