API Security Testing Checklist

An API security testing checklist turns a vague goal ("make sure the API is secure") into executable QA work. Modern products expose business logic through REST, GraphQL, and partner APIs. Attackers do not need your UI. They need an endpoint, a token, and an ID. If your team only tests screens, you are testing the wrapper and missing the engine.

This guide gives QA engineers a practical API security testing checklist covering authentication, authorization, injection, rate limits, transport, data exposure, and release gates. You will get prioritized checks, example cases, comparison tables, common mistakes, and a workflow you can run in staging before every serious release.

For auth deep dives, use API authentication testing. For risk language, use OWASP Top 10 for testers. For foundations, see the API testing tutorial and security testing for QA.

How to Use This Checklist

Do not print a hundred boxes and call it done. Use three layers:

1. Inventory: know your endpoints, methods, auth modes, and roles.
2. Critical path checks: every release candidate.
3. Deep checks: major releases, new resource types, or auth redesigns.

Mark each item as:

• Pass
• Fail
• Not applicable
• Risk accepted with owner and expiry

Evidence matters. Store request and response samples (sanitized), not just green ticks.

Prerequisites Before You Test

[ ] Written authorization for the environment
[ ] Staging or dedicated security test environment preferred
[ ] Test users for each role (guest, user, manager, admin, support)
[ ] At least two users in the same role for horizontal tests
[ ] API catalog or OpenAPI/Swagger graph
[ ] Ability to capture tokens and raw requests
[ ] Logging access or a security contact for noisy tests
[ ] Data cleanup plan for created resources

Without role fixtures, authorization testing becomes guesswork.

Layer 0: Inventory and Threat Sketch

Before payloads, list reality.

Field	Example
Base URL	https://api.staging.example.com
Spec	OpenAPI 3.1, last updated date
Auth modes	Bearer JWT, API key for partners
Roles	user, vendor_admin, staff, superadmin
Sensitive resources	users, invoices, payments, api_keys
Public endpoints	/health, /auth/login, /auth/register
Partner endpoints	/v1/partner/*
File or export endpoints	/reports/export
Webhooks	/webhooks/stripe

Threat sketch questions:

• What is the most valuable object?
• What is the most privileged action?
• Which IDs are guessable?
• Which endpoints change money, access, or personal data?

The API Security Testing Checklist

1) Transport and endpoint exposure

[ ] HTTPS enforced; HTTP redirects or fails closed
[ ] TLS configuration acceptable for your standard
[ ] No sensitive API accidentally exposed on public docs environments with real data
[ ] Admin APIs not reachable without network controls if design requires them
[ ] CORS policy is explicit; not Access-Control-Allow-Origin: * with credentials
[ ] Debug endpoints disabled outside local dev (/debug, /metrics with secrets, /graphiql in prod)

QA test idea: call http:// equivalent and confirm upgrade or hard fail. From a browser origin not in the allowlist, confirm credentialed cross-origin calls fail as designed.

2) Authentication essentials

[ ] Unauthenticated calls to protected routes return 401 (or consistent equivalent)
[ ] Invalid token rejected
[ ] Expired token rejected
[ ] Malformed token rejected
[ ] Token for disabled or deleted user rejected
[ ] Algorithm and signature validated for JWTs (no alg=none acceptance)
[ ] API keys not accepted in query strings if policy forbids them
[ ] Login/register rate limited
[ ] Password reset and OTP flows rate limited
[ ] Session or token revocation works after logout/password change where designed

Example cases:

ID	Check	Expected
AUTH-01	No Authorization header on GET /v1/invoices	401
AUTH-02	Token with bad signature	401
AUTH-03	Expired exp claim	401
AUTH-04	Token after password reset invalidation	401

Deepen JWT-specific testing with how to test JWT authentication and API authentication testing.

3) Authorization and object-level access (BOLA/IDOR)

This is often the highest value section of any API security testing checklist.

[ ] User A cannot read User B object by ID
[ ] User A cannot update/delete User B object by ID
[ ] Horizontal access denied across tenants or orgs
[ ] Vertical access denied: user cannot call admin endpoints
[ ] Role claims in tokens cannot be self-elevated by client edits
[ ] Nested resources checked (/users/{id}/documents/{docId})
[ ] Search and list endpoints do not leak other users' objects
[ ] Export endpoints honor the same authorization as UI
[ ] Predictable IDs tested (sequential integers, emails, usernames)
[ ] UUID resources still tested; secrecy of ID is not access control

Core horizontal probe:

1. As User A, create or note resource ID 1001.
2. As User B, request /resources/1001.
3. Expect 403 or 404 per design, never 200 with A's data.

Core vertical probe:

1. As standard user, call /admin/users.
2. Expect denial.
3. Confirm denial on POST/PUT/DELETE too, not only GET.

4) Function-level authorization

[ ] Hidden admin functions blocked server-side
[ ] Feature flags not trusted as authorization
[ ] Partner-only routes reject normal user tokens
[ ] Support tools cannot perform superadmin actions unless intended
[ ] Verb differences enforced (can read but not approve)

UI hiding is not security. If the route exists, test it.

5) Input validation and injection

[ ] Unexpected content types handled safely
[ ] Oversized payloads rejected
[ ] JSON depth and array size limits exist where needed
[ ] SQL/NoSQL injection probes blocked on filters and search params
[ ] Command injection vectors blocked on export/filename params
[ ] Path traversal blocked on file download parameters
[ ] SSRF risks reviewed on URL-fetching endpoints
[ ] GraphQL introspection disabled or locked down outside dev if required
[ ] GraphQL query depth/cost limits present for public APIs

Keep injection tests non-destructive in shared staging. Prefer detection of unsafe behavior over data destruction. See how to test for SQL injection and XSS testing guide for related techniques when APIs reflect content into web clients.

6) Mass assignment and extra fields

[ ] Client cannot set `role`, `isAdmin`, `balance`, `verified` unless allowed
[ ] Server ignores or rejects unknown dangerous fields
[ ] Patch semantics cannot overwrite protected fields
[ ] Nested object updates cannot reassign ownership

Probe:

PUT /v1/users/me
{
  "displayName": "QA User",
  "role": "admin",
  "emailVerified": true
}

Expected: profile name may update; privilege fields must not.

7) Business logic abuse

[ ] Negative quantities rejected
[ ] Coupon stacking rules enforced server-side
[ ] Multi-step workflows cannot skip approval steps
[ ] Race conditions considered for limited inventory or double spend
[ ] Idempotency keys honored on payment-like endpoints
[ ] State transitions validated (cannot ship a canceled order)

Security is not only cryptography. Business logic flaws are security flaws when they create unfair gain or data harm.

8) Rate limiting and anti-automation

[ ] Auth endpoints rate limited
[ ] Password reset rate limited
[ ] OTP resend rate limited
[ ] Expensive search/export endpoints limited
[ ] 429 responses consistent and safe (no sensitive leakage)
[ ] Limits apply per user/IP/API key as designed

QA method: script modest bursts in staging, confirm throttling, confirm legitimate users recover after window.

9) Sensitive data exposure

[ ] Tokens not returned in URL query logs
[ ] Passwords never returned in responses
[ ] PII minimized in error messages
[ ] Internal stack traces hidden outside dev
[ ] Secrets not present in response bodies
[ ] Backoffice fields not mixed into public DTOs
[ ] Pagination does not leak counts of hidden resources incorrectly
[ ] Backup or verbose debug headers absent

Compare list vs detail vs admin serializers. Many leaks are "extra fields" rather than dramatic breaches.

10) Headers and cache behavior

[ ] Cache-Control appropriate for authenticated responses
[ ] Sensitive GETs not publicly cacheable
[ ] Security headers present at edge where applicable
[ ] CORS preflight results match policy
[ ] Content-Type handled strictly on sensitive POSTs

11) Files, imports, and exports

[ ] Upload size and type validated server-side
[ ] Stored files served with safe content types
[ ] Export endpoints authorize per object and tenant
[ ] CSV/PDF generation does not include other tenants' rows
[ ] Filename parameters cannot escape storage roots

12) Webhooks and callbacks

[ ] Webhook signatures verified
[ ] Replay protection exists where required
[ ] Callback URLs cannot be set to internal-only addresses without controls
[ ] Partner webhooks reject unsigned bodies

13) Pagination, filtering, and bulk operations

[ ] page size capped
[ ] Negative offsets rejected
[ ] Filter language cannot escape authorization constraints
[ ] Bulk delete limited to authorized objects only
[ ] Bulk endpoints do not default to "all objects in system"

14) Logging, monitoring, and privacy

QA rarely owns SIEM, but can verify product expectations:

[ ] Failed auth events visible in intended logs
[ ] Secrets and raw passwords not written to application logs
[ ] Security-relevant admin actions auditable
[ ] Test alerts triaged with security owners when noisy

15) Dependency and version posture (lightweight for QA)

[ ] API versioning strategy understood
[ ] Deprecated endpoints documented and protected equally
[ ] Old app clients cannot call removed privilege shortcuts

Role Matrix Template

Build this for every critical resource type:

Action	Guest	User	Other user	Org admin	Staff admin
List own invoices	Deny	Allow	Deny	Allow (org)	Allow
Read invoice by ID	Deny	Own only	Deny	Org only	Policy
Refund invoice	Deny	Deny	Deny	Limited	Allow
Export all invoices	Deny	Deny	Deny	Org only	Allow

Turn each cell into a test case. This matrix alone can uncover more bugs than random payload lists.

Sample End-to-End API Security Smoke Pack

Run this on every release candidate:

1. Health public, admin not public.
2. Protected route without token -> 401.
3. User token on admin route -> 403.
4. User B cannot read User A object ID.
5. Mass assignment of role fails.
6. Expired token fails.
7. Login rate limit triggers under burst.
8. Error response has no stack trace.
9. Export endpoint honors authz.
10. HTTPS-only behavior confirmed in target environment.

If this pack fails, stop debating lower priority stylistic issues.

Comparison: Functional API Tests vs Security API Tests

Dimension	Functional API testing	API security testing
Main question	Does valid use work?	Can invalid or hostile use succeed?
Auth focus	Correct token works	Wrong/missing/forged token fails safely
Data focus	Schema and business correctness	Leakage, over-access, injection
Identity	Often one happy user	Many roles and cross-user pairs
Success metric	200 and correct body	Correct denial and no side effects
Tooling	Postman collections, contract tests	Same tools plus adversarial variants

You need both. A green functional suite can still hide IDOR.

Worked Example: Invoice API Mini Checklist

Endpoints:

• GET /v1/invoices
• GET /v1/invoices/{id}
• POST /v1/invoices
• POST /v1/invoices/{id}/refund

Critical tests:

1. User A lists invoices: only A data.
2. User B gets A's invoice ID: denied.
3. User B refunds A's invoice: denied.
4. User token posts refund when only finance role allowed: denied.
5. Refund with negative amount: rejected.
6. Refund replay with same idempotency key: no double refund.
7. Unauth refund: 401.
8. Response does not include internal fraud score fields for normal users.

This is an API security testing checklist applied to one resource, which is how real coverage grows.

Evidence and Defect Quality

Weak finding:

API insecure.

Strong finding:

Title: BOLA on GET /v1/invoices/{id} allows cross-user read
Actors: userA (tokenA), userB (tokenB)
Object: inv_123 owned by userA
Request as userB: GET /v1/invoices/inv_123
Actual: 200 with full invoice and customer email
Expected: 404 or 403 with no body leakage
Impact: Any authenticated user who can obtain or guess invoice IDs can read other customers' billing data
Evidence: sanitized response, IDs, timestamps

Common Mistakes

Mistake 1: Checklist without inventory

A generic PDF that never maps to your routes creates fake assurance.

Mistake 2: Only testing happy auth

Proving a valid token works is functional testing. Security starts when invalid power fails.

Mistake 3: One user account for all tests

You cannot test horizontal authorization with a single identity.

Mistake 4: Trusting UI-only coverage

If the button is hidden, the API may still be open.

Mistake 5: Ignoring list and search endpoints

Detail IDOR gets attention. Search leaks can dump many objects at once.

Mistake 6: No rate limit tests because "security owns bot protection"

Auth endpoint flooding is a product risk. Coordinate, then verify.

Mistake 7: Storing real production tokens in shared Postman workspaces

Hygiene is part of security. Use staging secrets and vault patterns.

Mistake 8: Never retesting after gateway changes

API gateways, WAF rules, and auth middleware changes can reintroduce old issues.

CI and Release Gate Suggestions

Gate	When	Examples
PR smoke	Every PR touching API	Unauth 401 on sample protected route, schema checks
Nightly	Every night	Role matrix subset, mass assignment probes
Release candidate	Before prod	Full critical checklist, rate limit spot checks
Post-incident	After security fix	Targeted regression pack

Automate the stable denials. Keep exploratory adversarial testing human-led.

Team Workflow That Works

1. Security and platform define standards and forbidden patterns.
2. Developers add authz tests next to handlers.
3. QA maintains role fixtures and release checklist evidence.
4. Pentest or red team performs periodic deep assessment.
5. All track exceptions with expiry dates.

QA is not a replacement for specialized offensive security. QA is the continuous net that keeps known classes from returning.

For continuous practice of security judgment under time pressure, create an account at QABattle sign-up and work through security and API battles in the app battles area.

Full Copy-Paste Release Checklist

API security release checklist
Inventory
[ ] Endpoint/role inventory reviewed for this release
[ ] New routes marked public/protected/admin/partner

Transport & exposure
[ ] HTTPS and CORS checks done
[ ] Debug surfaces off in target env

Authn
[ ] 401 on protected routes without credentials
[ ] Invalid/expired/malformed tokens rejected
[ ] Revocation/logout behavior verified if in scope

Authz
[ ] Horizontal object access denied
[ ] Vertical function access denied
[ ] List/search/export honor same rules

Inputs & logic
[ ] Mass assignment probes on create/update
[ ] Injection/path traversal probes on risky params
[ ] Business rule abuse cases for money/access flows
[ ] Rate limits on auth and expensive routes

Data & errors
[ ] No secrets/PII overexposure in responses
[ ] No stack traces on staging-prod-like configs
[ ] File/webhook paths checked if changed

Sign-off
[ ] Failures filed with evidence and owners
[ ] Risk acceptances documented with expiry
[ ] Regression cases added for fixed issues

Expanding the Checklist by API Style

REST resource APIs

Focus on object IDs, verbs, and serializers.

Extra checks:

[ ] PUT vs PATCH authorization equivalent where both exist
[ ] HEAD/OPTIONS do not leak sensitive existence info unexpectedly
[ ] Filtering syntax cannot bypass authz (`filter=ownerId!=me` tricks)
[ ] Sparse fieldsets do not reveal forbidden fields when requested

GraphQL APIs

[ ] Each mutation enforces authz independently
[ ] Nested selections cannot walk into unauthorized objects
[ ] Batching and aliases do not amplify auth bypasses
[ ] Cost limiting prevents trivial denial of service
[ ] Introspection policy matches environment

Partner webhooks and callbacks

[ ] Signature validation required
[ ] Timestamp tolerance prevents long replays
[ ] Event handlers are idempotent under retry
[ ] Partner cannot register endpoints pointing to internal cloud metadata without controls

Internal service-to-service APIs

Even "internal" APIs need checks if the network boundary is imperfect.

[ ] Service auth present (mTLS, signed tokens, network policies)
[ ] End-user identity propagated cannot be freely rewritten by callers without trust rules
[ ] Admin debug routes locked down

Threat Modeling Lite for QA

Before a major API release, spend thirty minutes on these prompts:

1. What is the most valuable object type in this API?
2. Who should never read it?
3. Who should never change it?
4. Which ID is easiest to obtain or guess?
5. Which endpoint is most expensive to call?
6. Which endpoint changes money, access, or personal data?
7. What happens if the client sends extra fields?
8. What happens if the client replays the same request?

Your API security testing checklist should grow from those answers, not from a generic internet PDF alone.

Evidence Pack for Audits and Enterprise Customers

Some buyers ask how you test API security. A reusable evidence pack can include:

• Sanitized role matrix for core resources
• CI job names for auth denial tests
• Last release candidate checklist results
• Sample ticket links for fixed BAC issues
• Dependency scanning policy summary
• Pentest date and remediation status if available

Do not hand over raw tokens or production dumps. Share process maturity.

Prioritizing When Time Is Short

If you only have half a day on a large API, run this order:

1. Authentication denials on protected routes
2. Horizontal object access on top three resources
3. Vertical admin function denials
4. Mass assignment on user/profile/org update
5. Sensitive data in error payloads
6. Rate limits on login
7. One export endpoint scope check
8. One file download authz check

This triage finds many of the bugs that become incidents.

Sample Postman Folder Structure

API Security
  00 Setup tokens
  01 Authn denials
  02 Horizontal access
  03 Vertical access
  04 Mass assignment
  05 Injection probes
  06 Rate limits
  07 Files and exports
  08 Webhooks

Use environment variables:

• token_user_a
• token_user_b
• token_admin
• id_resource_a

Never commit real secrets. Use a secret manager or local env files ignored by git.

Writing Security Assertions in Automated API Tests

Functional test:

expect status 200
expect invoice.total == 42

Security test:

as user_b:
  GET invoice_a
  expect status in [401, 403, 404]
  expect body not contains user_a.email

Both are necessary. Security assertions often check absence.

Handling False Positives and Design Ambiguity

Not every surprising 200 is a vulnerability. Sometimes a resource is intentionally shared.

When ambiguous:

1. Compare against the written access policy or story acceptance criteria.
2. Ask product: "Should User B see this?"
3. If unclear, file a question defect or spike note rather than silently ignoring it.
4. If product says deny, convert to a confirmed bug.

Security testing quality depends on knowing intended rules.

Connecting Checklist Items to OWASP API Risks

Checklist area	Related risk theme
Object ID access	Broken object level authorization
Admin functions	Broken function level authorization
Excess response fields	Excessive data exposure
Missing rate limits	Lack of resources and rate limiting
Mass assignment	Mass assignment
Auth token handling	Broken authentication
Business workflow skips	Business logic / misconfiguration themes
Injection probes	Injection

Use OWASP Top 10 for testers language in reports when it helps prioritization.

Weekly Operating Rhythm

• Monday: Review new endpoints merged last week; add matrix rows.
• Midweek: Run expanded security collection on staging.
• Friday: Verify fixed security tickets with evidence.
• Release day: Execute smoke pack and store results.

Continuity beats heroic annual checklists.

Final Expansion Note

An API security testing checklist is only as strong as the identities and objects behind it. Invest first in role fixtures and inventory quality. Then the checks in this guide become fast, repeatable, and difficult for regressions to escape.

Conclusion

A strong API security testing checklist is a living inventory of how your API can be abused, not a static poster on a wiki. Focus on authentication failures, object-level authorization, function-level authorization, mass assignment, injection, rate limits, and sensitive data exposure. Prove denials with multiple roles, keep evidence, and gate releases on the critical pack.

APIs are product surfaces. When QA treats them with the same seriousness as checkout screens, account takeover and data leak classes shrink dramatically. Use this checklist as your baseline, then specialize it for each domain object your business cannot afford to get wrong.