API Security Testing Checklist: 12 Checks Before You Ship

Security · Updated August 2026 · ← All tips

You don't need a penetration-testing background to catch the most common API vulnerabilities. Most of the OWASP API Security Top 10 can be probed with an ordinary REST client and a bit of discipline: send the request an attacker would send, and assert the API refuses it. Run these 12 checks against your own APIs — in staging, with authorization from your team — before every release.

Authorization — the #1 source of API breaches

1. Broken Object Level Authorization (BOLA/IDOR)

Log in as user A, then request user B's resource: GET /orders/{idOfUserB}. Expect 403 or 404 — never the data. Repeat for update and delete. This single test class finds more real-world API breaches than any other.

2. Broken function level authorization

Call admin endpoints (DELETE /users/{id}, GET /admin/reports) with a regular user's token. Changing a role should require admin rights — try PATCH /users/me with {"role": "admin"}.

3. Mass assignment

Send extra fields the UI never sends: {"name": "Ada", "isVerified": true, "balance": 9999}. If the API persists them, any client can set internal fields.

Authentication

4. Missing, expired and tampered tokens

• No Authorization header → expect 401 on every protected endpoint.
• Expired token → 401, not a silent success from a cache.
• Tampered JWT (change one character of the signature) → 401. If you sign test JWTs yourself, verify the API rejects alg: none and tokens signed with the wrong key.

5. Credential handling

Login errors should be generic ("invalid credentials"), the same for wrong user and wrong password, and rate-limited. Password reset tokens must be single-use and expire.

Data exposure

6. Excessive data in responses

Read the raw response body, not the UI. Look for password hashes, internal IDs, other users' emails, feature flags, stack traces. The API should return what the client needs — filtering in the frontend is not security.

7. Verbose errors

Force errors (bad JSON, wrong types, unknown routes) and check that responses never include stack traces, SQL fragments, framework versions or internal hostnames.

Input handling

8. Injection probes

In every string field and query parameter, try classic probes: ' OR '1'='1, <script>alert(1)</script>, ../../etc/passwd, {"$gt": ""} (NoSQL). Expect a clean 400/422 — a 500 means the input reached something it shouldn't have. A data-driven runner makes this systematic: one request, a CSV of payloads.

9. Content-type confusion

Send JSON with Content-Type: text/plain, XML to a JSON endpoint, an empty body to a POST. The API should reject, not guess.

Abuse resistance

10. Rate limiting

Loop 50–100 requests against login, signup, password reset and any expensive endpoint. Expect 429 to kick in. No limit on login means credential stuffing is free.

11. Unbounded pagination

Try ?limit=1000000. The API should clamp it, not attempt the query.

Transport & configuration

12. HTTPS and security headers

Plain http:// should redirect or refuse. Check for Strict-Transport-Security, a restrictive CORS policy (not Access-Control-Allow-Origin: * on authenticated endpoints), and that TLS certificate errors are never ignored in production clients.

Make these tests permanent. Every check above is one saved request plus one assertion. Keep them in a security/ folder in your collection, under version control, and run the folder on every release — a security regression then fails like any other test.