API security testing is the practice of probing application programming interfaces for vulnerabilities like BOLA, broken authentication, injection, and data exposure before attackers find them. It combines automated spec audits, dynamic scans, and runtime monitoring across the full API lifecycle.
Why are APIs the #1 attack target?
APIs handle the data that matters. Authentication tokens, payment details, personal records.
Every mobile app, SPA, and microservice talks through APIs. That makes them the most direct path to your data.
According to Salt Security’s 2024 State of API Security Report, 95% of organizations experienced an API security problem in the past 12 months.
The breach data tells the same story: T-Mobile lost 37 million records through an API in 2023, Optus lost 9.8 million through an unauthenticated endpoint in 2022.
Three factors make APIs especially vulnerable:
Volume. Most organizations have hundreds or thousands of API endpoints. Many are undocumented. You cannot test what you do not know exists.
Authorization complexity. A web page either loads or it does not.
An API endpoint might be accessible to some users, some roles, some scopes, and some IP ranges.
Testing every combination of who can do what on which object is a combinatorial problem.
Direct data exposure. APIs return structured data (JSON, XML) with all fields included. Web pages render only what the frontend shows.
An API might return a user’s SSN in the JSON response even if the mobile app never displays it.
OWASP API Security Top 10 explained
The OWASP API Security Top 10 (2023 edition) is the standard framework for API-specific risks. Use it as your testing checklist.
API1: Broken Object Level Authorization (BOLA). The API does not check whether the authenticated user owns the object they are requesting. Change /api/orders/123 to /api/orders/124 and get someone else’s order.
The most common API vulnerability and the hardest for automated tools to detect because it requires understanding the authorization model.
API2: Broken Authentication. Weak token generation, tokens that never expire, missing rate limiting on login endpoints, API keys in URLs.
Authentication mistakes are amplified in APIs because there is no browser managing sessions automatically.
API3: Broken Object Property Level Authorization. The API returns more data than needed (excessive data exposure) or accepts property modifications it should not (mass assignment).
Your user profile API returns is_admin: false in the response, and the update endpoint accepts is_admin: true in the request.
API4: Unrestricted Resource Consumption. No rate limiting, no pagination caps, no request size limits.
An attacker calls your expensive report-generation endpoint 10,000 times per minute and your cloud bill explodes.
API5: Broken Function Level Authorization. Regular users can access admin endpoints. GET /api/users works for everyone, but DELETE /api/users/123 should be admin-only and the API does not enforce it.
API6: Unrestricted Access to Sensitive Business Flows. Automated abuse of legitimate functionality. Mass account creation, inventory hoarding, coupon scraping.
The API works as designed, but the automation makes it a problem.
API7: Server-Side Request Forgery (SSRF). The API takes a URL as input and fetches it server-side.
The attacker points it at http://169.254.169.254/latest/meta-data/ to read cloud instance metadata.
API8: Security Misconfiguration. Missing security headers, verbose error messages exposing stack traces, CORS set to *, default credentials on API gateways.
API9: Improper Inventory Management. Old API versions still running in production, undocumented endpoints, shadow APIs nobody tracks. You cannot secure what you do not know about.
API10: Unsafe Consumption of APIs. Your application trusts responses from third-party APIs without validation.
If a partner API returns malicious data, your application processes it blindly.
For background on these risks and the tools that address them, see What is API Security?.
How I test APIs for security
My API security testing methodology is a five-pass loop that maps onto the OWASP API Top 10 without skipping the boring steps. I run it before a release and then again quarterly on the highest-risk endpoints.
Pass 1: Inventory and spec audit. I pull a fresh endpoint list from the API gateway, ingress rules, and production logs, then diff it against the OpenAPI spec. I feed the resulting spec through 42Crunch to catch missing auth, loose schemas, and sensitive data in URLs before I touch traffic.
Pass 2: Authentication and session. I try expired tokens, revoked tokens, tampered JWT claims, and missing signature verification. I also test rate limits on the login and password-reset endpoints, because that is where credential stuffing lives.
Pass 3: Authorization (BOLA and function-level). I create two accounts at different privilege levels and replay every request across both sessions. Burp Suite with the Authorize extension handles the replay; APIsec automates the same idea against an OpenAPI import.
Pass 4: Input handling and injection. I fuzz every parameter, path segment, and header with SQL, NoSQL, command, and SSRF payloads in JSON-aware form. I pay extra attention to endpoints that trigger server-side fetches or shell out to image and PDF tools.
Pass 5: Resource and business logic. I stress each endpoint for rate limits, pagination abuse (page_size=999999), oversized payloads, and deeply nested JSON. Then I walk through legitimate flows (signup, checkout, password reset) looking for abuse patterns like account enumeration or coupon stacking.
I log findings per endpoint with a reproducer, severity, and the OWASP API category, so the remediation ticket is self-contained. The whole pass is boring on purpose — consistency catches more bugs than cleverness.
Authentication and authorization testing
Authentication and authorization flaws (API1, API2, API3, API5) account for the majority of real-world API breaches. Test these first.
BOLA testing
BOLA testing requires at least two user accounts with different access levels. The process is straightforward:
- Authenticate as User A and make legitimate API requests. Record the object IDs in the requests and responses.
- Take those same requests, replace User A’s token with User B’s token, and replay them.
- If User B gets User A’s data, you have BOLA.
Do this for every endpoint that references object IDs. Pay attention to nested resources: /api/users/123/documents/456 might check authorization on the user ID but not on the document ID.
Burp Suite with the Authorize extension automates this. Record a session as an admin, configure the extension with a low-privilege token, and it replays every request with the lower-privilege credentials.
APIsec runs BOLA and RBAC playbooks automatically by importing your API specification and testing cross-user access on every endpoint.
Broken function-level authorization
Map your API endpoints by function: read, write, admin. Test whether each role can access functions outside its scope.
Pay particular attention to HTTP method combinations. An endpoint might enforce authorization on GET but not on PUT or DELETE.
Check for admin endpoints by guessing common patterns: /api/admin/users, /api/v1/internal/config, /api/debug. API documentation often excludes internal endpoints, but they may still be accessible.
Token testing
Check whether tokens expire. Generate a token, wait beyond its expected lifetime, and use it.
Test whether revoked tokens are actually rejected. Check what happens when you modify JWT claims (change role: user to role: admin).
If the server does not verify the signature, you have a critical vulnerability.
Tools like Burp Suite’s JWT Editor extension and jwt.io make JWT manipulation straightforward.
Injection testing for APIs
SQL injection, NoSQL injection, and command injection apply to APIs the same way they apply to web applications. The difference is the payload format.
SQL injection in APIs
API parameters are injection targets. Test every parameter that might reach a database query: path parameters (/api/users/123), query strings (?search=term), request body fields, and HTTP headers (custom headers used for filtering or sorting).
JSON-formatted payloads need adapted injection strings. A body field like {"username": "admin' OR '1'='1"} tests the same vulnerability as a form field, but the JSON encoding changes how the payload is delivered.
NoSQL injection
Many API backends use MongoDB or similar NoSQL databases. NoSQL injection uses different syntax: {"username": {"$ne": ""}, "password": {"$ne": ""}} bypasses authentication by matching any non-empty username and password.
Test for operator injection in every field that queries a NoSQL database. The payloads look different from SQL injection but the testing methodology is the same.
Command injection
APIs that interact with the operating system (file operations, process execution, system commands) are targets for command injection. Test parameters with shell metacharacters: ;, |, $(command), `command`.
Most modern frameworks prevent direct command injection, but APIs that shell out to system tools (ffmpeg, imagemagick, pdf converters) remain vulnerable if input is not sanitized.
Standard DAST tools like Burp Suite and StackHawk handle injection testing well. The API-specific step is ensuring every parameter in every endpoint gets tested, not just the obvious form fields.
Rate limiting and resource exhaustion testing
API4 (Unrestricted Resource Consumption) is often overlooked in security testing because it does not involve data theft. But it causes real damage. Service outages, inflated cloud bills, denial of service.
What to test
Per-endpoint rate limits. Send 1,000 requests per second to each endpoint.
If none return HTTP 429 (Too Many Requests), there is no rate limiting. Test with both authenticated and unauthenticated requests.
Per-user limits. Rate limiting by IP is easy to bypass with rotating proxies.
Per-user or per-API-key limits are harder to circumvent. Test whether rate limits track the right identifier.
Pagination abuse. Request ?page_size=999999 or ?limit=100000.
If the API returns all records without capping the page size, that is a resource exhaustion vulnerability. Also test with extremely large offset values.
Expensive operations. Identify endpoints that trigger heavy processing: report generation, search with complex filters, file conversion, bulk operations. These are the highest-risk targets for resource exhaustion.
Payload size limits. Send a 100MB JSON body. Send deeply nested JSON (1,000 levels deep).
Send a request with 10,000 array elements. The API should reject oversized and malformed payloads before processing them.
Tools for rate limit testing
Any HTTP load testing tool works: curl in a loop, Apache Bench, k6, or Locust. The point is not sophisticated tooling.
It is systematically checking that every endpoint has reasonable limits.
API Security Testing Tools
API security testing tools fall into three groups: design-time spec auditors, dynamic scanners that hit a running API, and runtime platforms that watch production traffic. Below are the tools I reach for most often, ranked by how frequently they show up in real engagements.
- Akto — Open-source API security testing platform with 1,000+ built-in tests and traffic-based discovery. The strongest free option for teams that want BOLA and auth-bypass coverage without a commercial contract.
- Salt Security — Runtime API security platform built on behavioral ML. Best for discovering shadow APIs and catching logic-based attacks that signature scanners miss.
- 42Crunch — Design-time auditor for OpenAPI specifications, scoring each spec from 0 to 100 against 300+ security checks. The free IDE extensions (VS Code, JetBrains, Eclipse) shift API security testing left into the editor.
- APIsec — Dynamic API security testing with 1,200+ playbooks covering BOLA, RBAC, and business logic. Supports REST, GraphQL, SOAP, and RAML with a free tier up to 100 endpoints.
- StackHawk — Developer-first DAST built for CI/CD. Define API tests in YAML, run them on every pull request, and block the merge on new findings.
- Wallarm — Combined WAF and API protection covering 160,000+ APIs per the vendor, with auto-discovery, OWASP API Top 10 coverage, and bot management.
- Traceable AI — Distributed-tracing-based API protection, now part of Harness since March 2025. Strong on east-west API visibility inside microservice meshes.
- Akamai API Security — Post-Noname platform that monitors external and internal API traffic, runs 150+ CI/CD security tests, and flags undocumented GenAI APIs.
- Burp Suite — Still the workhorse for manual API security testing. The Authorize (BOLA), JWT Editor, and InQL (GraphQL) extensions cover the API-specific gaps the default scanner leaves.
For a deeper head-to-head, see Salt Security vs 42Crunch. For the full catalog with pricing and license info, see the API security tools directory.
Automated API security testing in CI/CD
Manual API testing does not scale. If you have more than a handful of endpoints, you need automation in your pipeline.
Shift-left: spec auditing in PRs
Add 42Crunch API Security Audit to your CI pipeline. Every time a developer modifies an OpenAPI spec, the audit runs automatically and blocks the merge if the security score drops below your threshold. This catches design flaws before they become code.
Integration testing phase
After the API is deployed to a staging environment, run dynamic security tests. APIsec and StackHawk both offer CI/CD integrations that import your API spec, run security playbooks against the deployed API, and report findings in your pipeline.
Configure tests to cover at minimum: authentication bypass, BOLA on all endpoints with object IDs, injection on all input parameters, and rate limiting on public-facing endpoints.
Production monitoring
CI/CD testing catches known vulnerabilities. Runtime monitoring catches attacks in production and discovers APIs that CI/CD never tested (shadow APIs, third-party APIs, APIs deployed outside the pipeline).
Deploy Salt Security, Akamai API Security, or Wallarm to monitor production API traffic continuously. This is the layer that catches zero-days and business logic abuse.
How do you build an API security testing program?
If you are starting from scratch, here is a practical path.
Step 1: Inventory
You cannot test APIs you do not know about. Pull your API inventory from your API gateway, Kubernetes Ingress definitions, load balancer configurations, and cloud provider metadata.
Compare this against your documented API specs. The gaps are your shadow APIs.
If manual inventory is impractical, deploy an API discovery tool that analyzes network traffic. Salt Security and Akamai API Security both provide automated discovery.
Step 2: Prioritize by risk
Not all APIs need the same level of testing. Rank endpoints by the data they handle (PII, payment data, authentication) and their exposure (public, partner, internal).
Authentication endpoints, payment APIs, and anything returning personal data should be tested first.
Step 3: Test the critical ones
Run your highest-risk APIs through APIsec or test them manually with Burp Suite. Start with BOLA and authentication bypass. BOLA alone will likely turn up issues.
Step 4: Automate in CI/CD
Add spec auditing and dynamic API testing to your pipeline. Tools from the DAST tools category like StackHawk and Bright Security handle API scanning in CI/CD well.
Start with your highest-risk APIs and expand coverage over time.
Step 5: Monitor in production
Deploy runtime API monitoring. Start with discovery to validate your inventory.
Enable behavioral detection. Tune alerts. This is an ongoing process, not a one-time setup.
You will find real issues at every step. Do not wait for a complete program before you start testing.
