API Security Testing Checklist: OWASP API Top 10 and Beyond
APIs are the primary attack surface of modern applications. Every mobile app, SaaS integration, and microservice architecture exposes functionality through APIs that are often less rigorously tested than traditional web interfaces — because they are less visible, less understood, and not covered by the automated scanners most application security programs rely on.
This checklist covers the OWASP API Security Top 10 (2023 edition), the authentication and authorization edge cases that produce the highest-severity findings, injection and input validation tests, rate limiting and business logic issues, and the testing toolchain. It is written for application security engineers and penetration testers conducting API security assessments.
OWASP API Security Top 10: The Essential Coverage Baseline
The OWASP API Security Top 10 (2023) defines the most critical API vulnerability classes. Every API security assessment must cover all ten before expanding to additional test cases.
API1 — Broken Object Level Authorization (BOLA): The most prevalent API vulnerability. Test by enumerating object identifiers (user IDs, order numbers, document IDs) in API requests and substituting identifiers belonging to other accounts. If /api/v1/orders/12345 returns your order and /api/v1/orders/12346 returns another user's order without authorization, BOLA is confirmed. Horizontal privilege escalation via identifier manipulation is the defining characteristic.
API2 — Broken Authentication: Test all authentication mechanisms for weaknesses: credential brute-forcing with no lockout or rate limiting, predictable token formats that enable enumeration, missing token expiration on session tokens and password reset links, and lack of MFA on sensitive operations.
API3 — Broken Object Property Level Authorization (BOPLA): Authorization checked at the object level but not the field level. Test by submitting additional fields in request bodies that should not be modifiable: is_admin, account_balance, subscription_tier. If the API accepts and processes unauthorized fields, mass assignment is present.
API4 — Unrestricted Resource Consumption: Test for missing rate limits on computation-intensive endpoints: search with complex queries, file conversion, image processing, and bulk data export. Test for missing pagination limits on collection endpoints that could return millions of records.
API5 — Broken Function Level Authorization (BFLA): Authorization checks missing on function invocations rather than object access. Test by calling administrative API endpoints with standard user credentials: /api/admin/users, /api/v1/users/{id}/delete, /api/internal/reports. Check HTTP verb differences: does GET /api/users return only permitted users while DELETE /api/users/{id} lacks authorization checks?
API6 through API10 cover security misconfiguration (default credentials, verbose error messages, unnecessary HTTP methods), server-side request forgery in URL parameters, security logging gaps, unsafe API consumption of third-party data, and improper inventory management (shadow APIs, deprecated versions still accessible).
Authentication and Authorization Deep Tests
Beyond the OWASP baseline, authentication and authorization testing requires specific attack scenarios that automated scanners routinely miss.
JWT attack testing is mandatory for any API using JSON Web Tokens. Test the algorithm confusion attack: modify the JWT header to change alg from RS256 to HS256, then sign the token with the server's public key (which is often accessible). If the server validates HS256-signed tokens using its public key as the HMAC secret, any user can forge valid tokens for any account. Test the none algorithm attack: change alg to none and remove the signature — some implementations accept unsigned tokens. Test for weak signing keys by running the token through jwt_tool or hashcat with a rockyou wordlist.
OAuth 2.0 misconfiguration testing covers redirect_uri validation bypass (append additional paths, use subdomains, test open redirectors on the registered domain), state parameter CSRF (test flows with missing or reused state values), token leakage via Referer headers (check whether the authorization code appears in server logs or downstream Referer headers), and scope escalation (request a token with a minimal scope, then test whether that token accepts requests for higher-privileged scopes).
Vertical privilege escalation testing: obtain a standard user JWT, then replay API requests that should be restricted to admin roles. Check every request your admin-level account can make and attempt replay with a user-level token. Automated tools miss this because they require understanding of the application's role model — it requires manual identification of privileged functions before testing.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Input Validation: Injection and Parameter Pollution
API injection vulnerabilities differ from traditional web application injection in their attack surface: JSON and XML body parameters, HTTP headers, and URL path components are all injection points that web-focused scanners may not fuzz adequately.
SQL injection in API parameters is still prevalent despite its age. Test all string parameters that appear to query data: add single quotes, boolean conditions (and 1=1, and 1=2), and time-based payloads (sleep(5)). JSON body parameters deserve equal attention to URL query strings. Test nested JSON keys — some ORMs apply injection protections to top-level parameters but not to nested objects.
NoSQL injection is common in document database-backed APIs. Test for MongoDB operator injection by submitting JSON operator payloads in string parameters: {"username": {"$gt": ""}} should not bypass authentication in a MongoDB backend. Use Burp Suite's Hackvertor extension to generate NoSQL injection payloads for common MongoDB, Elasticsearch, and Redis backends.
HTTP parameter pollution occurs when an API processes multiple values for the same parameter differently depending on whether they appear in the URL query string, request body, or headers. Test by submitting duplicate parameters with conflicting values and observing which value the application uses: this can bypass input validation applied to only one parameter source.
Server-side request forgery via URL parameters: any parameter that accepts a URL should be tested for SSRF. Submit internal addresses (http://169.254.169.254/latest/meta-data/ for AWS metadata, http://localhost:6379/ for Redis), cloud metadata endpoints, and internal service addresses. Blind SSRF requires out-of-band detection via Burp Collaborator or interactsh.
Rate Limiting, Business Logic, and GraphQL
Rate limiting tests are among the highest business-impact findings and among the most commonly skipped in time-constrained assessments.
Test rate limiting on all sensitive endpoints: authentication (login, password reset, email verification, MFA code entry), financial operations (payment initiation, balance transfers, coupon code redemption), resource-intensive operations (file upload, conversion, report generation), and data export (bulk export, CSV download). For each, test both per-IP and per-account rate limits — bypassing per-IP limits by rotating through proxies is a common evasion technique. Test whether rate limiting survives across HTTP/1.1 and HTTP/2 connections to the same endpoint.
Business logic testing requires manual analysis of the application's intended behavior. Common high-value findings include: negative value abuse in financial parameters (submit -100 in a quantity field to add funds instead of deducting), workflow step skipping (can you reach step 3 of a checkout flow without completing steps 1 and 2?), referral and promotional code stacking (can multiple discount codes be applied simultaneously?), and price manipulation (submit a lower price in a server-accepted price parameter).
GraphQL security requires specific testing approaches not covered by REST API tooling. Introspection queries (__schema, __type) reveal the full API schema when not disabled in production — test with a raw introspection query to verify whether it is disabled. Batch query abuse allows sending hundreds of queries in a single HTTP request, bypassing rate limiting that counts requests but not query count. Deeply nested queries (5-plus levels of nested object resolution) can cause exponential backend load — test with progressively deeper query nesting and observe response time degradation. Field suggestion attacks exploit GraphQL's did you mean feature to enumerate valid field names even when introspection is disabled.
Testing Toolchain: Burp Suite, Nuclei, and Postman
API security testing requires a different toolchain emphasis than web application testing, with heavier reliance on manual interception and scripted automation.
Burp Suite Professional is the primary tool for manual API security assessment. Its Scanner covers basic injection and authentication issues but misses authorization logic — the majority of BOLA and BFLA findings require manual testing. The Repeater module is essential for replaying requests with modified parameters. The Intruder module handles brute-force attacks against authentication endpoints and identifier enumeration for BOLA testing. Install the JWT Editor extension for in-line JWT manipulation and the Param Miner extension for discovering undocumented parameters.
Nuclei with the nuclei-templates repository provides automated scanning against known API vulnerabilities: exposed Swagger UIs, unauthenticated admin endpoints, default credentials on API management platforms, and CVEs in common API frameworks. Run nuclei -t http/exposed-panels/ and nuclei -t http/misconfiguration/ against your target before beginning manual testing to identify low-hanging fruit quickly.
Postman is valuable for API collection management and automated functional testing that can be extended for security. Import the target API's OpenAPI specification, generate test cases for each endpoint, and use Postman's scripting layer to add authorization bypass tests (swap tokens between accounts, remove authorization headers, test with expired tokens). The OWASP API Security Testing Checklist Postman collection (available on Postman's public workspace) provides a pre-built test suite mapped to OWASP API Top 10.
42Crunch Audit and Scan automates OpenAPI specification security review and DAST scanning. It identifies security issues in the OpenAPI definition itself (missing authentication requirements, overly permissive parameter types, missing response schemas) before testing the live API.
The bottom line
API security testing cannot be fully automated. BOLA, BFLA, and business logic vulnerabilities require manual analysis of the application's authorization model, workflow sequencing, and intended behavior. Cover the OWASP API Top 10 as the mandatory baseline, then extend to JWT and OAuth attacks, business logic edge cases, and GraphQL-specific risks if applicable. Use Burp Suite for manual testing, Nuclei for automated common vulnerability coverage, and 42Crunch for OpenAPI specification review. Shift left by reviewing OpenAPI specifications for security requirements before implementation — requiring authentication on all endpoints, defining input validation constraints, and specifying rate limiting requirements at the design stage is cheaper than finding missing controls in testing.
Frequently asked questions
How is API security testing different from web application security testing?
Web application testing focuses heavily on browser-rendered interfaces: XSS, CSRF, clickjacking, and client-side logic. API testing focuses on machine-to-machine communication patterns: authorization logic across object and function boundaries, data serialization handling, schema validation, rate limiting, and programmatic authentication mechanisms. APIs expose data and functionality more directly than web interfaces, often without the rendering-layer controls that prevent some attack classes. BOLA, mass assignment, and business logic flaws are far more prevalent in APIs than in traditional web applications. The toolchain differs too — Burp Suite is used in both, but API testing relies more on direct HTTP manipulation and less on browser-mediated interception.
What is BOLA and why is it the top API vulnerability?
Broken Object Level Authorization (BOLA) occurs when an API endpoint accepts a resource identifier from the client and returns or modifies that resource without verifying that the requesting user is authorized to access it. An attacker who discovers that /api/v1/invoices/1234 returns their invoice can simply try /api/v1/invoices/1235 to access another user's invoice if BOLA is present. It is the top API vulnerability because authorization at the object level is a business logic check that cannot be implemented automatically — it requires developers to explicitly verify ownership for every data access operation. Automated scanners cannot reliably detect BOLA because they do not understand the application's ownership model.
How do I test for BOLA at scale across many endpoints?
BOLA testing requires two test accounts in different security contexts. Perform all actions with Account A and capture the resulting API requests in Burp Suite's proxy history. Then replay each captured request substituting Account B's authentication token while retaining Account A's resource identifiers in the URL and request body. Any request that returns Account A's data using Account B's token is a BOLA finding. Automate this pattern using Burp Suite's Authorizer extension, which replays every proxied request with an alternate authorization token and flags responses that differ from the unauthenticated baseline — a useful starting point, though manual review of flagged responses is still required.
What are the most common JWT vulnerabilities to test?
The five highest-priority JWT vulnerabilities to test: algorithm confusion (change alg from RS256 to HS256 and sign with the public key), none algorithm acceptance (remove alg and signature), weak HMAC secret (brute-force with jwt_tool and common password wordlists), missing expiration validation (replay expired tokens to verify rejection), and kid (Key ID) injection (inject SQL or path traversal payloads into the kid header parameter if the server uses it to select signing keys). Use Burp Suite's JWT Editor extension to perform all of these tests without leaving the proxy workflow.
How should I approach API security testing for GraphQL?
GraphQL requires a different testing approach from REST. First, check whether introspection is enabled: send a raw __schema query and review the full type and field inventory if it responds. If introspection is disabled, use field suggestion probing to enumerate valid field names. Test for batch query rate limiting by sending 100 queries in a single request body. Test for deeply nested query denial of service by building recursive queries that require exponential resolver execution. Test for BOLA in GraphQL by querying object types with identifiers belonging to other accounts. Check whether mutations (write operations) have the same authorization controls as queries — mutation-level authorization is often implemented less rigorously than query-level.
What OpenAPI specification security issues should I check before testing the live API?
Review the OpenAPI specification for security issues before live testing to identify design-level problems that will manifest as vulnerabilities: missing security scheme definitions on endpoints (means no authentication is required), overly permissive parameter types (string parameters without maxLength allow injection and buffer manipulation), missing response schema definitions (leads to unintended data exposure when responses return more fields than documented), and undocumented endpoints discoverable through fuzzing but not present in the spec (shadow APIs often lack any security review). 42Crunch Audit automates OpenAPI specification security review and maps findings to the OWASP API Security Top 10.
How do I test rate limiting on API endpoints?
Test rate limiting by sending requests at progressively higher rates until either a rate limit response (429 Too Many Requests) is received or the test volume exceeds a reasonable attacker capability without triggering limits. Use Burp Suite Intruder in Sniper mode with a null payload and high thread count for basic rate limit testing. For per-IP rate limit bypass testing, use Burp Suite's IP Rotate extension or a proxy pool to distribute requests across multiple source IPs. Test whether the X-Forwarded-For, X-Real-IP, or True-Client-IP headers can be used to spoof the source IP and bypass per-IP rate limits — this is a common misconfiguration in APIs deployed behind load balancers.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.