How to Test API Security

APIs have become the primary interface between systems, mobile apps, third-party integrations, and microservices. They are also the number one attack vector for modern web applications. Unlike traditional web pages where a user fills out forms and clicks buttons, API security testing requires examining raw HTTP requests, authentication tokens, authorization logic, and data serialization formats that are invisible to typical browser-based testing. If you are responsible for securing applications that expose REST, GraphQL, or gRPC endpoints, understanding how to test API security is no longer optional.

This guide covers the methodology, tooling, and common pitfalls of API vulnerability scanning, from manual exploration to automated pipeline integration.

TL;DR

API security testing follows five phases: discovery, authentication, authorization, injection, and business logic testing.
The highest-severity bugs are authorization flaws (BOLA/IDOR), not injection vulnerabilities -- test logic first, injection second.
Start with API discovery -- you cannot test what you do not know exists. Hunt for exposed Swagger/OpenAPI specifications.
Automated scanners catch ~80-90% of injection and discovery issues, but authorization testing remains largely manual.
Integrate API scanning into CI/CD pipelines to catch new vulnerabilities before they ship to production.

Why API Security Testing Matters

APIs are fundamentally different from web pages. A web page can enforce business logic through UI constraints -- disabling a button, hiding a field, limiting dropdown options. An API has none of these guardrails. Every parameter, every header, and every endpoint is directly accessible to anyone who can construct an HTTP request.

This creates three categories of risk that traditional web scanning misses:

Business logic bypass: An attacker modifies a user ID in a request path to access another user's data. The server returns a valid 200 response because no authorization check exists at the object level.
Excessive data exposure: An API returns the full user object -- including internal fields like password_hash, is_admin, or internal_notes -- because the serializer was never configured to filter sensitive attributes.
Undocumented endpoints: Development, debug, or admin API routes that were never removed from production. These often lack authentication entirely.

The OWASP API Security Top 10

The OWASP API Security Top 10 is the definitive classification of API-specific risks. Unlike the general OWASP Top 10 (which focuses on web applications), this list addresses the unique attack patterns that affect APIs. Here are the categories you need to test for:

API1: Broken Object Level Authorization (BOLA)

The most prevalent API vulnerability. An authenticated user modifies an object identifier (like /api/users/123 to /api/users/456) and accesses data belonging to another user. Testing involves systematically changing IDs in every endpoint that references a resource. This is hard to catch with automated scanners because the response looks completely normal -- a valid 200 with well-formed JSON. The only signal is that the data belongs to someone else.

API2: Broken Authentication

Weak or missing authentication mechanisms: APIs that accept expired tokens, fail to validate JWT signatures, allow brute-force attacks against login endpoints, or expose credentials in URLs. Test by sending requests with no token, expired tokens, tokens from other users, and tokens with modified claims.

API3: Broken Object Property Level Authorization

Even when a user is authorized to access an object, they may not be authorized to access or modify all its properties. An API that lets you PATCH /api/users/me with {"role": "admin"} has this flaw. Test by submitting unexpected fields in create and update requests.

API4: Unrestricted Resource Consumption

APIs without rate limiting, pagination limits, or resource quotas. An attacker can exhaust server resources by requesting massive result sets, triggering expensive computations, or flooding authentication endpoints.

API5-10: Additional Categories

The remaining categories cover broken function-level authorization (accessing admin endpoints), unrestricted access to sensitive business flows, server-side request forgery (SSRF), security misconfiguration, improper inventory management (shadow APIs), and unsafe consumption of third-party APIs.

API Security Testing Methodology

Effective API security testing follows a structured approach. Randomly throwing payloads at endpoints will miss the authorization and logic flaws that represent the highest risk.

Phase 1: API Discovery and Documentation

Before you can test an API, you need to know it exists. Start by hunting for OpenAPI/Swagger specifications -- these are the blueprint of an API's endpoints, parameters, and expected data types. Common locations include:

/swagger.json, /swagger.yaml, /openapi.json
/api-docs, /v1/docs, /api/swagger-ui.html
/.well-known/openapi.json
JavaScript source files that embed API routes and base URLs

Tools like Metric Tower's SwaggerJacker automate this discovery, probing dozens of common spec locations and parsing the results into a list of testable endpoints. Once you have a spec (or have manually mapped the API by observing traffic), catalog every endpoint, HTTP method, and parameter.

Phase 2: Authentication Testing

Authentication testing verifies that the API correctly identifies who is making a request. Key tests include:

No-auth access: Send every request with no authentication header. Any endpoint that returns data without auth is a finding.
Token validation: Send requests with expired tokens, malformed tokens, and tokens with modified payloads. For JWTs, test the alg: none bypass and key confusion attacks.
Credential stuffing resistance: Test login/token endpoints for rate limiting, account lockout, and brute-force protection.
Token leakage: Check if tokens appear in URLs, error messages, logs, or HTTP referrer headers.

Phase 3: Authorization Testing (BOLA/IDOR)

This is where the highest-severity API bugs live. Authorization testing verifies that authenticated users can only access resources they own.

The core technique is simple: authenticate as User A, capture a request that accesses User A's resource (e.g., GET /api/orders/order-123), then replay that request with User B's token. If User B gets User A's data, you have a Broken Object Level Authorization vulnerability.

Scale this across every endpoint that takes an object identifier: user IDs, order IDs, file IDs, team IDs, invoice IDs. Test both horizontal escalation (user-to-user) and vertical escalation (user-to-admin). For UUIDs, don't assume they're unguessable -- check if any endpoint leaks them in list responses.

Common Mistake

Assuming UUIDs prevent BOLA attacks. While UUIDs are harder to guess than sequential integers, list endpoints often leak them. Always check whether one authenticated user can access another user's resources regardless of ID format.

Phase 4: Injection Testing

API injection testing follows the same principles as web injection testing, but applies to different input vectors:

JSON body parameters: SQL injection through {"search": "'; DROP TABLE users;--"}
Query parameters: NoSQL injection through operators like $gt, $ne, $regex
Path parameters: Path traversal through /api/files/../../etc/passwd
Header values: SSRF through headers like X-Forwarded-For, X-Original-URL
GraphQL queries: Introspection dumps, nested query DoS, batch query attacks

Phase 5: Business Logic and Rate Limiting

Test the constraints that should exist but often don't:

Rate limiting: Can you send 10,000 requests per second to the login endpoint? To the password reset endpoint? To the payment endpoint?
Pagination abuse: Does ?limit=999999 dump the entire database?
Mass assignment: Can you set is_admin, price, or discount on a create/update request?
Race conditions: Can you redeem a coupon twice by sending concurrent requests?

Tools for API Security Testing

No single tool covers all five phases. Effective API testing combines automated scanners with manual exploration.

Automated Discovery: Finding the API Surface

SwaggerJacker probes for exposed OpenAPI/Swagger specification files, then parses them to extract every route, parameter, and schema definition. It also tests whether endpoints documented as requiring authentication are actually enforced. This alone frequently reveals undocumented admin routes, debug endpoints, and deprecated API versions that were never decommissioned.

Arjun discovers hidden HTTP parameters by fuzzing endpoints with a wordlist of common parameter names and analyzing response differences. Many APIs accept undocumented parameters -- debug=true, admin=1, internal=yes -- that change application behavior.

Automated Scanning: Vulnerability Detection at Scale

Nuclei runs template-based checks against discovered endpoints. With over 11,000 community-contributed templates, it covers known CVEs, default credentials, exposed admin panels, API key leakage, and misconfigured CORS policies. For API testing specifically, look at the http/exposures/apis/ and http/vulnerabilities/ template directories.

Sensitive-file detection checks for .env files, .git directories, database dumps, and configuration files that are commonly exposed alongside API endpoints.

Manual Testing: The Human Layer

Burp Suite remains the gold standard for interactive API testing. Its proxy captures every request, letting you modify parameters, replay requests with different auth tokens, and detect subtle differences in responses that indicate authorization flaws. The Intruder module automates BOLA testing by iterating through object IDs.

Postman is excellent for building structured test collections that exercise every endpoint. Use its scripting capabilities to chain requests (create a resource, capture its ID, try to access it from another account) and automate regression testing.

Common API Vulnerabilities in Practice

Here are the patterns that appear most frequently in real-world API security assessments:

Broken Object-Level Authorization (BOLA)

This vulnerability is present in an estimated 40% of APIs. The fix is straightforward -- every data-access query must include a WHERE user_id = :current_user or equivalent ownership check -- but it's easy to miss when hundreds of endpoints are involved.

Frameworks that don't enforce scoping by default (most of them) leave this entirely to the developer.

Best Practice

Implement scoping at the framework level, not per-endpoint. In Laravel, use global scopes or policy classes. In Express, use middleware that automatically filters by the authenticated user's ownership. This prevents developers from accidentally forgetting a check.

Excessive Data Exposure

APIs that return full database objects instead of purpose-built response DTOs. A mobile app's user profile endpoint returns the user's hashed password, internal notes, and subscription tier because the serializer sends the entire Eloquent model. The fix is explicit response schemas -- never return a model directly.

Mass Assignment

APIs that bind request bodies directly to model updates without filtering allowed fields. An attacker adds "role": "admin" to a profile update request and the server obediently sets it. The fix is an explicit allowlist of fields that the endpoint accepts -- never use $request->all() for model creation.

Missing Rate Limiting

Login endpoints, password reset endpoints, and payment endpoints without rate limiting. A single attacker can brute-force credentials, enumerate valid emails, or abuse expensive operations. Rate limiting should be applied per-endpoint with appropriate thresholds.

Best Practice

Never return full database models directly from API endpoints. Use explicit response DTOs or serializers that whitelist returned fields. This prevents sensitive internal fields from leaking when new columns are added to the database.

Automating API Security in Your Pipeline

Point-in-time testing catches existing vulnerabilities. Continuous testing catches new ones before they ship. The most effective approach combines both.

Metric Tower's API security scanner chain runs SwaggerJacker for API discovery, feeds discovered endpoints to Arjun for parameter discovery, then pipes everything into Nuclei and the sensitive-files scanner for vulnerability detection. This entire chain executes automatically as part of a scan, with results tracked across runs so you can see when new API endpoints appear and whether previously found vulnerabilities have been fixed.

For CI/CD integration, trigger scans against staging environments before deployment. The API supports programmatic scan creation and result retrieval, so you can fail a pipeline when critical or high-severity API findings are detected. See our guide to automated vulnerability scanning for the full CI/CD setup.

Checklist: API Security Testing Coverage

Use this as a minimum coverage checklist for any API security assessment:

The numbers above reflect a practical reality: automated tools excel at discovery and injection testing, but authorization logic is application-specific and requires human judgment. A strong API security program combines automated scanning for the mechanical checks with manual testing for the business logic.

Next Steps

Key Takeaways

1 Start with API discovery -- exposed Swagger specs, hidden parameters, and undocumented endpoints are the foundation of everything that follows.
2 Prioritize authorization testing (BOLA/IDOR) over injection testing -- authorization flaws are the most common and highest-severity API vulnerabilities.
3 Combine automated scanning for injection and discovery with manual testing for business logic -- no single tool covers both effectively.
4 Integrate API security scanning into your CI/CD pipeline to catch new vulnerabilities before they reach production.

If you are just starting with API security testing, begin with discovery. You cannot test what you do not know exists. Run a spec discovery tool against your domains, enumerate your API surface, and build a catalog of every endpoint. From there, prioritize authorization testing on your highest-risk endpoints, then layer in automated injection scanning for broad coverage.

For teams that want to automate this workflow, Metric Tower chains SwaggerJacker, Arjun, Nuclei, and sensitive-file detection into a single scan that discovers, inventories, and tests your API surface with results tracked over time. You can also explore our comparison of API security testing tools to find the right combination for your needs.