API Security Testing: Finding Vulnerabilities Before Attackers Do

Every modern application is an API. Your mobile app talks to an API. Your single-page application talks to an API. Your partner integrations, your webhook receivers, your microservices mesh -- they are all APIs. And according to the 2025 Salt Security State of API Security report, API attacks increased 681% over the previous two years, while overall API traffic grew only 321%.

The gap between API growth and API attack growth tells a clear story: organizations are deploying APIs faster than they are securing them. Traditional web application firewalls (WAFs) and network-level scanners were designed for a different era. They cannot reason about business logic flaws, authorization boundaries, or data exposure patterns that are unique to API architectures.

The OWASP API Security Top 10 (2023): What Actually Gets Exploited

The OWASP API Security Top 10 is the definitive taxonomy of API vulnerability classes. Understanding each category is essential for building a comprehensive testing program.

API1: Broken Object-Level Authorization (BOLA)

BOLA is the single most common and most exploited API vulnerability. It occurs when an API endpoint accepts an object identifier (user ID, order ID, document ID) and fails to verify that the authenticated user has permission to access that specific object.

The attack is trivially simple. An authenticated user sends GET /api/users/123/records and receives their own records. They then send GET /api/users/124/records and receive someone else's records. No exploit kit required. No buffer overflow. Just changing a number in the URL.

BOLA is devastating because it scales. An attacker can enumerate thousands of object IDs in minutes and exfiltrate entire databases through legitimate-looking API calls that do not trigger rate limits or WAF rules.

Testing for BOLA requires:

• Creating two accounts with different permission levels
• Capturing valid requests from Account A
• Replaying those requests using Account B's authentication token
• Verifying that Account B is denied access to Account A's objects

API2: Broken Authentication

Authentication flaws in APIs go beyond weak passwords. Common patterns include:

• JWT validation failures: Accepting tokens with alg: none, failing to validate issuer claims, using symmetric secrets that can be brute-forced, or not checking token expiration
• API key leakage: Keys embedded in client-side code, committed to git repositories, or logged in server access logs
• Missing authentication on internal endpoints: Endpoints intended for service-to-service communication that are accidentally exposed without auth checks
• Credential stuffing without rate limiting: Login endpoints that allow unlimited authentication attempts per IP or per account

API3: Broken Object Property-Level Authorization (BFLA)

Even when an API correctly verifies that a user can access an object, it may expose properties that the user should not see. A GET /api/users/123 response that includes salary, ssn, or isAdmin fields alongside name and email is a BFLA vulnerability. Mass assignment attacks, where an attacker sends extra fields in a PUT/PATCH request (like "role": "admin") and the server blindly persists them, fall under this category.

API4: Unrestricted Resource Consumption

APIs that lack rate limiting, pagination limits, or request size restrictions are vulnerable to denial-of-service and data harvesting. Common patterns include:

• Search endpoints that return unlimited results without pagination
• File upload endpoints with no size limits
• GraphQL endpoints that allow deeply nested queries (query depth attacks)
• Batch endpoints that process unlimited items per request

API5-10: The Remaining Critical Categories

The remaining OWASP API Top 10 categories cover equally important ground:

• API5 - Broken Function-Level Authorization: Users accessing admin-only endpoints by guessing URL patterns (/api/admin/users)
• API6 - Unrestricted Access to Sensitive Business Flows: Automating business flows (ticket purchasing, coupon redemption) faster than intended
• API7 - Server-Side Request Forgery (SSRF): APIs that fetch user-supplied URLs can be tricked into accessing internal services
• API8 - Security Misconfiguration: Verbose error messages, CORS wildcards, missing security headers, debug endpoints in production
• API9 - Improper Inventory Management: Shadow APIs, deprecated endpoints still accessible, undocumented admin routes
• API10 - Unsafe Consumption of Third-Party APIs: Trusting data from external APIs without validation or sanitization

Building an API Security Testing Program

Effective API security testing combines automated scanning with manual review. Neither alone is sufficient. Automated tools excel at finding injection flaws, misconfigurations, and known CVEs in frameworks. Manual testing is required for business logic flaws, authorization boundary testing, and complex multi-step attack chains.

Phase 1: API Discovery and Inventory

You cannot test what you do not know exists. API sprawl is a real problem in modern organizations. Development teams deploy new endpoints continuously, and deprecated endpoints rarely get decommissioned.

Build your API inventory from multiple sources:

• OpenAPI/Swagger specifications: The authoritative source if kept up to date. Many teams generate these from code annotations.
• API gateway logs: Traffic analysis reveals endpoints that exist in production but are not documented.
• Source code analysis: Scan route definitions in your codebase to find endpoints that may not appear in specifications.
• Proxy traffic capture: Use Burp Suite or mitmproxy during QA testing to passively discover API endpoints as testers exercise the application.

Phase 2: Automated Scanning

Feed your API specifications into automated testing tools for baseline coverage:

# Example: Running OWASP ZAP against an OpenAPI spec
zap-api-scan.py -t https://api.example.com/openapi.json \
  -f openapi -r api-scan-report.html \
  -c zap-api-config.yaml

# Example: Nuclei templates for API-specific checks
nuclei -u https://api.example.com \
  -t api/ -t cves/ -t exposures/ \
  -header "Authorization: Bearer $TOKEN" \
  -severity critical,high -o findings.json

Automated tools will find injection vulnerabilities (SQLi, XSS, command injection), misconfiguration issues (CORS, security headers, verbose errors), and known CVEs in API frameworks. They will not find BOLA, BFLA, or business logic flaws. Those require manual testing.

Phase 3: Manual Authorization Testing

This is where the critical findings live. For every API endpoint, you need to verify:

1. Horizontal access control: Can User A access User B's resources by manipulating object identifiers?
2. Vertical access control: Can a regular user access admin-only endpoints or operations?
3. Field-level access control: Does the API expose fields in responses that the requesting user should not see?
4. State-based access control: Can a user perform operations that should be unavailable based on the current state of an object (e.g., modifying a submitted order)?

Phase 4: Continuous Testing in CI/CD

API security testing must be continuous, not periodic. Integrate automated scans into your CI/CD pipeline so that every deployment is tested before reaching production. Contract testing frameworks like Pact can verify that API changes do not inadvertently remove authorization checks.

API Security Testing Tools: What to Use Where

No single tool covers all API security testing needs. A mature testing program uses multiple tools for different purposes:

• Burp Suite Professional: The gold standard for manual API testing. Its repeater, intruder, and autorize extension make authorization testing efficient.
• OWASP ZAP: Open-source alternative to Burp for automated scanning. Strong OpenAPI integration for spec-driven testing.
• Nuclei: Template-based scanner with an extensive community library. Excellent for known CVE detection in API frameworks and custom check development.
• Postman/Newman: Not a security tool, but essential for building reproducible test collections that verify authorization boundaries.
• GraphQL-specific tools: InQL (Burp extension) and GraphQL Voyager for schema introspection and query complexity analysis.

Common API Security Anti-Patterns

Beyond the OWASP Top 10, several anti-patterns consistently appear in API security assessments:

• Security through obscurity: Relying on undocumented endpoints to remain hidden. Attackers use fuzzing and JavaScript analysis to discover them.
• Client-side enforcement only: Hiding UI elements but not enforcing permissions server-side. The API is the enforcement boundary, not the frontend.
• Sequential integer IDs: Using auto-incrementing database IDs as API identifiers makes enumeration trivial. Use UUIDs or opaque identifiers.
• Over-fetching by design: Returning entire database objects instead of selecting only the fields the client needs. This leads to accidental data exposure.
• Missing audit logging: APIs without access logs make incident investigation impossible. Log every authenticated request with user identity, endpoint, parameters, and response code.

GraphQL-Specific Security Considerations

GraphQL APIs introduce unique vulnerability classes that REST-focused testing misses:

• Introspection in production: GraphQL introspection queries expose your entire schema to anyone who asks. Disable introspection in production or restrict it to authenticated admin users.
• Query depth and complexity attacks: Deeply nested queries can cause exponential server-side computation. Implement query depth limits and complexity scoring.
• Batching attacks: GraphQL naturally supports batching multiple operations in a single request. Without rate limiting per operation (not per request), attackers can bypass rate limits.
• Authorization at the resolver level: GraphQL resolvers must enforce authorization independently. A common mistake is checking auth at the query level but not at nested field resolvers.

The Bottom Line

API security testing is fundamentally different from traditional web application security testing. The most critical vulnerabilities -- broken authorization, business logic flaws, data exposure -- cannot be found by automated scanners alone. They require understanding the business context of each endpoint and testing whether the authorization model holds under adversarial conditions.

Start with a complete API inventory. Automate what can be automated (injection testing, misconfiguration checks, known CVE detection). Then invest manual testing time where it matters most: authorization boundaries. The breaches that make headlines are almost never injection attacks. They are authorization failures that let one user access another user's data at scale.