API Security Testing

Why APIs are 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.

Akamai’s 2024 State of the Internet report found that API attacks grew 109% year-over-year. Salt Security reported that 95% of organizations experienced an API security incident 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?.

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:

1. Authenticate as User A and make legitimate API requests. Record the object IDs in the requests and responses.
2. Take those same requests, replace User A’s token with User B’s token, and replay them.
3. 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-specific security tools

Different tools cover different parts of the API security testing lifecycle.

Design-time audit

42Crunch audits OpenAPI specifications against 300+ security checks and scores them from 0 to 100. The free IDE extensions (VS Code, JetBrains, Eclipse) let you check specs during development. It catches things like missing authentication requirements, overly permissive schemas, and sensitive data in URL parameters before any code is written.

Dynamic API testing

APIsec runs 1,200+ security playbooks against your APIs, including BOLA and RBAC tests that generic DAST tools miss. Supports REST, GraphQL, SOAP, and RAML. Free tier available for up to 100 endpoints.

Burp Suite is still the go-to for manual testing. Its scanner handles injection and misconfiguration checks. Extensions like Authorize (for BOLA), JWT Editor, and InQL (for GraphQL) add API-specific capabilities.

StackHawk is designed for CI/CD. Define your API tests in YAML, run them on every pull request, and get results in your pipeline.

Runtime discovery and monitoring

Salt Security discovers shadow APIs by analyzing traffic from API gateways and cloud environments. Its behavioral ML detects BOLA and logic-based attacks that signature-based tools miss.

Akamai API Security monitors both external and internal API traffic, runs 150+ CI/CD security tests, and discovers undocumented GenAI APIs.

Wallarm combines WAF and API protection, covering 160,000+ APIs with auto-discovery, OWASP API Top 10 coverage, and bot management.

For a deeper comparison, see Salt Security vs 42Crunch. For the full category, see API security tools.

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.

Building 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. 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.

FAQ

Frequently Asked Questions

Written by

Suphi Cankurt

Suphi Cankurt is an application security enthusiast based in Helsinki, Finland. He reviews and compares 129 AppSec tools across 10 categories on AppSec Santa. Learn more.