API Security Testing Checklist: A Practical Guide

Why APIs Deserve Their Own Checklist

A web application checklist applied to an API misses the issues that matter most. Browsers enforce CORS, same-origin, and cookie scoping for you. APIs typically run without any of that, so authorisation has to be enforced explicitly on every endpoint and every object. The most damaging API breaches in recent years (data leaks at telecoms, fitness platforms, retailers, and SaaS providers) have come from broken object level authorisation, not from injection or XSS.

APIs also expose more granular surface area than the UI suggests. A single screen in a web app may call ten endpoints; a partner integration may call a hundred. Each endpoint is its own decision point. A checklist focused on the right risks (authorisation, authentication, schema, rate limits, business logic) catches the issues that scanners consistently miss.

For broader application coverage and tooling guidance, see the web application penetration testing checklist and application security testing tools guide.

1. Scoping and Pre-Test Preparation

Most weak API tests start with weak scoping. Get this phase right and the rest of the engagement is straightforward.

• Inventory the endpoints: request an OpenAPI, Swagger, GraphQL schema, or Postman collection. If none exists, plan extra time for discovery via traffic capture, route enumeration, and mobile or SPA traffic analysis. Improper inventory management is its own OWASP API Top 10 category for a reason.
• Identify environments: test in a dedicated staging environment that mirrors production data shapes (with synthetic data) and authentication providers. Production testing requires explicit authorisation and tighter rules of engagement.
• Get test accounts: obtain at least two accounts per role (admin, regular user, viewer) and at least two tenants. Two accounts per role lets you test horizontal authorisation; two tenants lets you test vertical isolation in multi-tenant systems.
• Confirm rate limits and WAF rules: if a WAF will throttle or block your testing, request an allow-list for the test source IPs. Otherwise the engagement tests the WAF, not the API.
• Verify domain ownership: any external API testing should follow domain verification and recorded authorisation. SecPortal supports DNS TXT or meta tag verification before any external scan runs.
• Define the rules of engagement: authorised IPs, testing windows, escalation contacts, data handling for any sensitive content, and what to do if real customer data appears in responses.

2. Authentication Testing

Broken authentication remains the second most reported API risk. Modern APIs typically authenticate with bearer tokens (JWT, opaque tokens, OAuth access tokens, API keys), mTLS, or session cookies. Each has distinct failure modes.

Token handling

• Verify tokens are signed and the signature is actually verified on the server
• Test for the classic JWT algorithm confusion: alg=none, alg=HS256 with RS256 public key
• Check token expiry is enforced; replay an expired token to confirm rejection
• Confirm refresh tokens rotate on use and are invalidated on logout
• Look for tokens leaking via logs, referer headers, error messages, or query strings
• Decode JWTs with the JWT decoder to inspect claims, scope, and audience values

Login flows

• Test for username enumeration via timing differences and error messages
• Check rate limits and lockout policies on login, MFA, and password reset
• Verify MFA is enforced server-side, not just client-side
• Test password reset for token reuse, predictable tokens, and host header injection
• Confirm OAuth flows validate state parameters, redirect URIs, and PKCE where applicable

API keys and machine-to-machine

• Test that API keys are scoped (read vs write, per-environment, per-tenant)
• Check key rotation and revocation paths actually invalidate active sessions
• Look for keys leaked in client-side bundles, mobile app binaries, or public repositories

3. Authorisation Testing (BOLA, BFLA, BOPLA)

This is where most serious API findings live. The OWASP API Top 10 lists three distinct authorisation failures, all of which require active manual testing.

Track each authorisation test as a separate finding template in your tracker so they can be retested individually after fixes. SecPortal's findings management ships with templates for the OWASP API Top 10.

4. Input Validation and Injection

APIs are exposed to the same injection classes as web applications, plus a few that are more API-specific. Test methodically rather than throwing a scanner payload list at every parameter.

• SQL and NoSQL injection in any parameter that flows into a database query
• OS command injection where user input is shelled out (filenames, hostnames, search terms)
• Server-side template injection in any field rendered into emails, PDFs, or templated responses
• SSRF via URL parameters, webhooks, image fetchers, and PDF generators
• XML external entity (XXE) where the API accepts XML, including SOAP and SAML endpoints
• Header injection (CRLF) in any field reflected into response headers
• JSON injection and prototype pollution in nested object parameters
• Open redirect via redirect_uri or return_url parameters
• Improper deserialisation in fields that hydrate complex objects (Java, .NET, Python pickle)

For deeper coverage of dynamic testing, see the DAST guide and authenticated vs unauthenticated scanning.

5. Rate Limiting and Resource Consumption

Unrestricted resource consumption combines availability risk with cost risk. Even when an attacker cannot exfiltrate data, an unmetered endpoint can drive cloud bills or cause cascading outages.

• Test login, password reset, MFA, and OTP endpoints for brute-force protection
• Verify per-user, per-IP, and per-tenant limits and confirm headers communicate the limit
• Send oversized request bodies; APIs commonly fail to enforce a maximum payload size
• Send deeply nested JSON or GraphQL queries to exhaust parser memory
• Trigger expensive operations (report generation, search, batch endpoints) repeatedly
• Check pagination limits; some APIs accept page=10000000 and try to allocate
• Confirm file upload endpoints enforce size, type, and concurrency limits

6. Business Logic and Sensitive Flows

Scanners cannot find business logic flaws. They require understanding the application, forming hypotheses, and testing them. Spend at least a third of the engagement on logic.

• Race conditions in payments, coupon redemption, withdrawals, and one-time actions
• Replay of state-changing requests (idempotency keys missing or unverified)
• Negative or extreme values in money, quantity, and time fields
• Workflow skipping (POST /order/confirm without /order/payment)
• Multi-tenant boundary tests across every cross-tenant relationship
• Bulk endpoints accepting object IDs from other tenants in the same payload
• Webhook signature validation (replay, signature stripping, downgrade)
• Privilege boundary at every role transition (invite, accept, leave, remove)

7. GraphQL and gRPC Specifics

REST is not the whole story. GraphQL and gRPC add testing concerns of their own.

GraphQL

• Introspection should be disabled in production unless intentionally public
• Test query depth and complexity limits with deeply nested or fan-out queries
• Authorisation at the resolver level, not just the entry query
• Batching abuse: sending an array of 1,000 mutations in a single request
• Field-level authorisation on sensitive types (user, billing, audit)
• Schema-aware fuzzing of every input type and enum value

gRPC

• Reflection should be disabled in production
• Authorisation interceptors enforced on every method, including streaming methods
• Message size limits to prevent resource exhaustion
• Transport security (mTLS) and certificate pinning for sensitive paths

LLM-backed APIs

Any API endpoint that wraps a large language model needs a separate test pass for prompt injection (OWASP LLM01). This is a distinct vulnerability class from traditional injection because the model itself follows attacker instructions; the API layer has to compensate.

• Test direct injection in every prompt-driven endpoint, including chat, search, and summarisation
• Plant indirect injection payloads in retrieval sources (uploaded files, indexed pages, tickets)
• Confirm every tool the model can invoke is gated by independent server-side authorisation
• Verify the API treats model output as untrusted before rendering, parsing, or acting on it
• Test cross-tenant leakage when a shared retrieval index serves multiple customers

8. Continuous Automated Coverage

Manual API testing is high signal but slow. Combine it with continuous automated coverage so the routine surface area never drifts unmeasured between assessments.

• Run an authenticated dynamic scan on a recurring schedule. SecPortal's authenticated scanning stores credentials with AES-256-GCM encryption and runs 17 modules behind login
• Add SAST and SCA into your CI to catch insecure patterns and vulnerable dependencies before they reach the API
• Track headers, TLS, and exposure on every public host with the external scanner
• Use continuous monitoring to schedule scans daily, weekly, or monthly and detect regressions across releases
• Treat every CI failure as a finding so the audit trail is unified

For programme structure, see building a continuous security monitoring programme.

9. Reporting and Remediation

A long list of findings without context is rarely actioned. Structure findings so engineering can pick them up and so auditors get the evidence they need.

• Map each finding to an OWASP API Top 10 category (and CWE where applicable)
• Score every finding with CVSS and verify with the CVSS calculator
• Include reproduction requests as raw HTTP, not screenshots, so engineers can copy them
• Provide a fix recommendation that names the layer (gateway, framework, code) where it belongs
• Distinguish between defence-in-depth and the underlying root cause
• Deliver findings in a portal that supports retest and persistent remediation status, not only PDF

See the security assessment report template and how to write a pentest report for the full reporting structure.

The Quick Checklist

A condensed version to use during the engagement.

1. Inventory every endpoint from spec, traffic, mobile, and SPA bundles
2. Confirm at least two accounts per role and two tenants for authorisation testing
3. Test JWT signature verification, expiry, and algorithm confusion
4. Test login, MFA, and password reset for rate limits and enumeration
5. BOLA test every object-ID endpoint across users and tenants
6. BFLA test admin endpoints with low-privilege tokens
7. BOPLA test for mass assignment and excessive data exposure
8. Run injection sweeps (SQLi, NoSQLi, command, SSRF, XXE, SSTI)
9. Validate input sizes, depths, batch sizes, and pagination limits
10. Hunt business logic flaws on payments, coupons, workflows, and webhooks
11. Test GraphQL introspection, depth, complexity, batching, resolver authorisation
12. Test gRPC reflection, message limits, interceptor coverage
13. Run continuous authenticated and external scans alongside the manual test
14. Map findings to OWASP API Top 10, score with CVSS, deliver in a portal with retest

Frequently Asked Questions About API Security Testing