API Penetration Testing Checklist: 85 Checks Mapped to the OWASP API Top 10

An API penetration testing checklist keeps a test focused on the risks that actually cause API breaches. The 85 checks below follow the natural order of an engagement: scope, discover, authenticate, then attack authorization, properties, inputs, business logic, and configuration. Each phase lists its OWASP API Security Top 10 category so your report maps cleanly to a recognized standard.

This article was created with AI assistance. Test only systems you own or are explicitly authorized to test.

How to use this checklist

• For a manual pentest: work through the phases in order and record evidence for each check, including “not applicable” with a reason.
• For a scanner evaluation: mark which checks your tool performs automatically. The gaps are what your manual testing or threat modeling must cover.
• For a release gate: automate the authorization, authentication, and configuration phases on every release candidate, and schedule the rest.

Phases 3 to 5 depend on Phase 1. Without two users per role and two tenants, you cannot test BOLA, BFLA, or tenant isolation at all.

Phase 1: Scope and preparation

Most failed API tests fail before the first request: the wrong environment, a single test account, or no agreement on what is in scope. OWASP mapping: all categories.

1. Get written authorization that names the hosts, environments, and testing window.
2. Agree on excluded systems, maximum request rates, and an escalation contact for incidents.
3. Use a non-production environment with production-like configuration and disposable test data.
4. Create at least two users per role, plus users in two different tenants or organizations.
5. Seed each test user with objects they own (orders, invoices, projects, files) so cross-user tests have targets.
6. Collect the API definition: OpenAPI/Swagger spec, Postman collection, or recorded HAR traffic.

Phase 2: Discovery and inventory

You can only test what you know exists. Build a complete operation inventory before testing anything else. OWASP mapping: API9 Improper Inventory Management.

1. List every operation (method + path) from the spec and compare it with what the gateway or traffic shows.
2. Request older version prefixes such as /v1/, /v2/, /beta/, and /internal/.
3. Check for publicly exposed schema documents (/openapi.json, /swagger.json, /api-docs, GraphQL introspection).
4. Probe for debug, health, metrics, and admin surfaces (/actuator, /debug, /metrics, /admin).
5. Identify every parameter that carries an object identifier: path, query, body, and headers.
6. Identify every parameter that accepts a URL, file, or XML document.
7. Record which operations change state (POST, PUT, PATCH, DELETE) and which move money or create accounts.
8. Map the expected access for each operation and role. This matrix drives the authorization phase.

Phase 3: Authentication

Authentication bugs let attackers become someone else. Test the token, the login, and the recovery paths. OWASP mapping: API2 Broken Authentication.

1. Call every protected operation with no credentials and confirm a 401.
2. Send malformed, truncated, and random tokens; confirm they are rejected without stack traces.
3. Replay an expired token and confirm rejection; check how long access tokens remain valid.
4. Set the JWT alg header to none and remove the signature.
5. Re-sign a JWT with a different key, and test HS256/RS256 algorithm confusion.
6. Modify JWT claims (subject, role, tenant) without re-signing and confirm the signature is enforced.
7. Try to brute-force common secrets for HMAC-signed tokens using an offline wordlist.
8. Compare login and password-reset responses for existing and non-existing accounts to detect enumeration.
9. Send repeated failed logins and confirm throttling, lockout, or CAPTCHA.
10. Test default and well-known credentials on admin and service accounts.
11. Confirm tokens are invalidated on logout and password change.
12. Confirm that sensitive actions (email change, password change, MFA reset) require re-authentication.

Phase 4: Authorization

This is the highest-value phase. Most serious API breaches come from authorization failures, and they are invisible to single-user testing. OWASP mapping: API1 BOLA, API5 BFLA.

1. For every operation with an object ID, replay User A’s request with User B’s ID (same role).
2. Repeat cross-user tests for read, update, and delete—protection on GET does not imply protection on PATCH or DELETE.
3. Replay requests across tenants with IDs from the other organization.
4. Test identifiers in every location: path, query string, JSON body, nested objects, and custom headers.
5. Check list, search, and export endpoints for records belonging to other users.
6. Try predictable IDs (sequential integers) and IDs leaked by other responses for UUID-based APIs.
7. Call every admin-only operation with every lower-privilege role.
8. Call privileged operations with alternate HTTP methods on the same path.
9. Change role or tenant hints in the request (X-Tenant-ID, ?orgId=, body fields) and see whether the server trusts them.
10. Check whether a user can attach another user’s object to their own (for example, add someone else’s payment method to an order).
11. Confirm that error responses for unauthorized objects do not reveal whether the object exists.
12. Re-run the full authorization matrix after every role or permission change.

Phase 5: Object properties

Even when access to an object is correct, individual fields can leak or be overwritten. OWASP mapping: API3 Broken Object Property Level Authorization.

1. Review each response for fields the client does not need: internal IDs, hashes, tokens, flags, other users’ personal data.
2. Compare responses for the same object across roles; lower roles should see fewer fields.
3. Add privileged properties to create and update requests (role, isAdmin, ownerId, tenantId, status, price).
4. Read the object back after each write to confirm whether injected properties persisted.
5. Send properties in nested objects and arrays, not only at the top level.
6. Check whether read-only fields in the schema (readOnly: true) are actually enforced on write.

Phase 6: Input handling and injection

Injection is no longer a standalone API Top 10 category, but it remains common in APIs that build queries or commands from input. OWASP mapping: API8 Security Misconfiguration, API7 SSRF.

1. Test string parameters for SQL injection using error-based, boolean, and time-based techniques.
2. Test JSON bodies for NoSQL operator injection ({"$ne": null}, {"$gt": ""}).
3. Test parameters that reach shells or file names for command injection.
4. Test parameters rendered into templates or emails for server-side template injection.
5. Test file and path parameters for traversal (../ and encoded variants).
6. Send XML to endpoints that accept it and test for XXE.
7. Supply internal addresses and a callback URL you control to every URL parameter (SSRF).
8. Send wrong types, nulls, very long strings, and unexpected enum values; confirm 4xx responses, not 500s.
9. Upload files with dangerous extensions, mismatched content types, and oversized payloads.
10. Confirm that validation errors do not leak stack traces, SQL, or framework versions.

Phase 7: Business logic

Business-logic flaws use valid requests in invalid sequences or with invalid values. Scanners help with common patterns; your threat model covers the rest. OWASP mapping: API6 Unrestricted Access to Sensitive Business Flows.

1. Tamper with client-supplied prices, totals, discounts, and currencies.
2. Submit negative, zero, fractional, and very large quantities.
3. Change the payment amount between authorization and capture.
4. Skip steps in multi-step flows (checkout, onboarding, approval) by calling the final step directly.
5. Replay one-time actions: coupon redemption, referral credit, trial activation.
6. Race concurrent requests against limited resources (inventory, balances, invites).
7. Automate high-value flows (sign-up, reservations) at speed and check for anti-automation controls.
8. Confirm that state transitions (for example, refunded → shipped) are validated server-side.

Phase 8: Rate limiting and resource consumption

Unbounded APIs are expensive to run and easy to take down. OWASP mapping: API4 Unrestricted Resource Consumption.

1. Check for 429 responses and rate-limit headers on login, OTP, and password-reset endpoints.
2. Request very large page sizes (?limit=100000) and deeply nested expansions.
3. Send batch requests with thousands of items.
4. Trigger costly third-party actions (SMS, email, document generation) repeatedly.
5. Upload files beyond the documented maximum and confirm rejection before processing.
6. Confirm that timeouts and request-size limits are enforced at the gateway and the service.

Phase 9: Configuration and transport

Misconfiguration checks are quick and highly automatable. Run them on every environment. OWASP mapping: API8 Security Misconfiguration.

1. Confirm TLS everywhere and that plain HTTP redirects or is refused.
2. Send an arbitrary Origin header and check whether it is reflected with Access-Control-Allow-Credentials: true.
3. Check for server and framework version headers.
4. Confirm unused HTTP methods (TRACE, PUT on read-only resources) are disabled.
5. Check security headers relevant to API responses (Cache-Control on sensitive data, Content-Type correctness).
6. Trigger errors and confirm generic messages in non-debug mode.
7. Confirm that internal endpoints are not reachable from the internet.
8. Check that secrets do not appear in responses, logs exposed through APIs, or client bundles.

Phase 10: Third-party APIs and webhooks

Data from integrations deserves the same suspicion as user input. OWASP mapping: API10 Unsafe Consumption of APIs.

1. Send unsigned or incorrectly signed webhook payloads and confirm rejection.
2. Replay a valid webhook and confirm idempotency or replay protection.
3. Review whether data from partner APIs is validated before use in queries, redirects, or decisions.
4. Confirm outbound calls use TLS and do not follow redirects to arbitrary hosts.

Phase 11: Reporting and retesting

A finding is only useful if an engineer can reproduce it and you can prove it is fixed. OWASP mapping: all categories.

1. Record the exact request, response, user, and role for every finding.
2. Map each finding to an OWASP API Top 10 category and a severity.
3. Write remediation guidance that names the control, not only the symptom.
4. Retest every fixed finding and record the result.
5. Convert confirmed findings into automated regression tests so they stay fixed.

Which checks to automate

Roughly two-thirds of this checklist can run automatically on every release if your scanner understands your API definition and your roles. The authorization phase is the most valuable to automate, because it is tedious by hand—every operation multiplied by every role multiplied by every owner—and because authorization regressions are easy to introduce in new endpoints.

DastPilot automates the rows marked above from an OpenAPI spec or Postman collection plus your role definitions, and records the request and response behind every finding. Pair it with a focused manual test of business flows, and use our CI/CD guide to make the automated part run on every release.

Frequently asked questions

What should an API penetration test include?

At minimum: endpoint discovery, authentication and token testing, object- and function-level authorization testing with multiple users and roles, property-level checks for mass assignment and data exposure, injection testing, business-logic abuse, rate limiting, configuration review, and a report with reproducible evidence.

How long does an API penetration test take?

It depends on the number of operations and roles. A small API with a few dozen operations may take a few days manually; large APIs take weeks. Automating authentication, authorization, and configuration checks shortens the manual portion considerably.

Do I need more than one test account?

Yes. Authorization flaws such as BOLA, BFLA, and cross-tenant access can only be detected by comparing what different users and roles can access. Plan for at least two users per role and two separate tenants.

How often should APIs be penetration tested?

Run automated security tests on every release and schedule manual penetration tests at least annually or after major architectural changes. Many compliance programs require an annual test; continuous automated testing catches regressions between them.