APIs have become the primary attack surface of modern web applications. Mobile apps, SPAs, and third-party integrations all communicate through APIs. Internal microservices communicate through APIs. The traditional web application security model — test the forms, test the redirects, test the upload handlers — misses the majority of the actual attack surface in most products built after 2018.
And yet API security testing is inconsistent at most engineering teams. The OWASP API Security Top 10 (the 2023 edition significantly expanded from 2019) documents vulnerability patterns that appear in production APIs regularly — Broken Object Level Authorization, Broken Authentication, Excessive Data Exposure, Lack of Resources and Rate Limiting — none of which are new categories, all of which keep appearing because API testing hasn't kept pace with API development.
Why API security testing is different from web app testing
Web application security testing has established tooling: OWASP ZAP and Burp Suite have been scanning HTML forms for injection and XSS vulnerabilities for over a decade. Both tools have evolved to handle APIs, but their default configuration is oriented toward web crawling and form-based testing.
REST APIs and GraphQL APIs require a different testing approach. The attack surface is defined by an OpenAPI specification (if you have one), by the API calls your client applications make, or by reverse-engineering from documentation or proxy capture. Without a complete picture of the API surface, automated tools will miss endpoints they don't know exist.
The most impactful API vulnerabilities — BOLA (Broken Object Level Authorization, OWASP API1) and BFLA (Broken Function Level Authorization, OWASP API5) — are authorization logic issues that can't be found by scanning tool alone. Finding BOLA requires testing whether user A can access user B's resources by manipulating object IDs in API requests. A tool can generate that test, but only if it has two authenticated sessions (as two different users) and knows which parameters are object references.
Building an API security testing approach your team can run
The goal isn't to replicate what a professional penetration tester does over five days. It's to build systematic coverage of the API security risks that are most likely to be present in your application, at a cadence that engineering teams can sustain.
Start with your OpenAPI specification. If you have an OpenAPI (Swagger) or similar spec, use it. Tools like OWASP ZAP's OpenAPI scanner, Spectral with the API security ruleset, and 42Crunch's API security audit can analyze the spec for security issues before you even run a test: missing authentication requirements, overly permissive schemas, excessive response data exposure. Linting your OpenAPI spec in CI is a five-minute setup and catches a subset of security issues without running any HTTP traffic.
Run authenticated functional tests with a security lens. Your existing API test suite tests that the API returns correct data. Run the same tests logged in as a different user, or with the object IDs swapped to another user's resources. Does the API return a 403 or a 200 with someone else's data? This is BOLA/IDOR testing. It requires no specialized security tool — just your existing test framework and a second test user.
Use Burp Suite or OWASP ZAP for exploratory testing. Proxy your API traffic through Burp Suite Community (free) or OWASP ZAP while walking through your application manually. This captures the actual request/response pairs including the endpoints your automated tests might not cover. Once captured, run the active scanner against the captured traffic to find injection, authentication, and other automated-detectable issues.
The OWASP API Security Top 10 as a testing checklist
The 2023 OWASP API Security Top 10 is a useful structure for systematically covering the most common vulnerability classes:
API1: Broken Object Level Authorization. For every API endpoint that returns a specific resource by ID (GET /api/orders/12345), test whether an authenticated user can access another user's resource by substituting their ID for another valid ID. This is the most common API vulnerability in production applications.
API2: Broken Authentication. Test token expiration, check that logout actually invalidates server-side session state, verify that JWT algorithm restrictions are enforced, test for credential stuffing protection (rate limiting on auth endpoints).
API3: Broken Object Property Level Authorization. Does the API return more fields than necessary? Can users update fields they shouldn't be able to (mass assignment)? Send a PATCH or PUT request with unexpected fields — does the API accept and apply them?
API5: Broken Function Level Authorization. Are admin-only endpoints accessible to regular users? Test by making admin API calls while authenticated as a regular user. Look for endpoints that rely on the UI to hide them rather than server-side authorization to restrict them.
API8: Security Misconfiguration. Check HTTP security headers, CORS configuration (overly permissive CORS is a common API finding), TLS configuration, and whether debug endpoints are enabled in production.
GraphQL-specific testing considerations
GraphQL APIs present a different testing surface than REST. Introspection — the ability to query the schema itself — should be disabled in production (many implementations leave it enabled by default). Unbounded query depth can cause denial of service: a deeply nested GraphQL query can execute a combinatorial number of resolver calls. Field-level authorization needs to be tested at the resolver level, not just at the operation level.
Tools like InQL (a Burp Suite extension for GraphQL testing) and graphql-cop provide specific GraphQL security testing capabilities that generic web scanners don't cover well.
What this doesn't replace
This approach covers the systematic testing that engineering teams can run as part of their development and release process. It doesn't replace a professional penetration test for high-risk API surfaces — authentication systems, payment APIs, APIs that handle health data or financial transactions. Pen testing provides adversarial creativity and depth that systematic checklist-driven testing doesn't replicate.
The goal of an engineering team's API security testing program is to find the obvious issues — the BOLA findings, the missing rate limiting, the overly permissive CORS — before they're found by an attacker or a pen tester. That level of coverage is achievable with the tools and approach described here, without requiring a dedicated security tester on the team.
