API Security Testing: What DAST Misses and How to Fill the Gap

Understanding why standard DAST misses APIs requires understanding how DAST crawling works. A DAST crawler starts at a URL, parses the HTML response, extracts links, forms, and JavaScript references, and follows them recursively to build a site map of testable inputs. API endpoints typically do not appear in HTML. They are called by JavaScript code, mobile applications, or backend services using HTTP requests that the crawler never generates. Even if a DAST crawler identifies an API endpoint URL from a JavaScript bundle, it cannot construct an authenticated request with a valid JWT, cannot produce a structurally valid JSON body that the API accepts, and cannot understand the resource relationships that authorization testing depends on.

API inventory is the prerequisite for API security testing. An organization cannot test what it does not know exists. Four complementary discovery methods cover the range of API exposure points. Network traffic analysis from a web application proxy or API gateway captures all API calls made by real users and applications, revealing endpoints that may not be documented anywhere. OpenAPI/Swagger specification files, if they exist, provide the most complete inventory of intended API surface; the presence of a spec file at /api/openapi.json, /swagger.json, or /v2/api-docs is a reliable indicator. API gateway logs from AWS API Gateway, Kong, Apigee, or similar platforms capture every API call including path, method, and response codes, making them a comprehensive source for endpoint enumeration. JavaScript bundle analysis extracts API base URLs and endpoint patterns from client-side code; tools like LinkFinder and JSParser automate this extraction.

Inventory completeness is a measurement challenge. After running all four discovery methods, compare the resulting endpoint list against what the development team believes exists. The gap between discovered endpoints and documented endpoints is the shadow API surface: endpoints that exist in production but are not in the official inventory. Shadow APIs are typically older endpoints that were never removed, internal endpoints accidentally exposed to external networks, or development and staging endpoints reachable from production. Each category carries a distinct risk profile but all require inclusion in the security testing scope.

The OWASP API Security Top 10 2023 defines the most common and impactful API vulnerability categories. Three categories dominate real-world API breaches and warrant the most testing investment: Broken Object Level Authorization (API1:2023), Broken Authentication (API2:2023), and Unrestricted Access to Sensitive Business Flows (API6:2023).

Broken Object Level Authorization (BOLA), also called Insecure Direct Object Reference (IDOR), occurs when an API endpoint accepts a resource identifier from the client and returns or modifies that resource without verifying that the requesting user is authorized to access it. A typical pattern: GET /api/orders/12345 returns an order. The API authenticates the user but does not check whether order 12345 belongs to the authenticated user. An attacker who enumerates order IDs can access every order in the system regardless of ownership. BOLA is the most prevalent API vulnerability class because it requires explicit per-resource authorization checks at every endpoint, and this check is easy to forget, particularly for internal or administrative APIs where the assumption is that only authorized internal clients will call them.

Broken Authentication covers weak token implementation, missing token validation, and predictable token formats. Common findings include JWT tokens with alg:none accepted by the server (the signature is bypassed entirely), API keys transmitted in query parameters that appear in server access logs, missing token expiration enforcement, and refresh tokens with indefinitely long validity periods. Testing authentication requires attempting authentication bypass at each endpoint rather than only testing the login flow.

Mass Assignment (API6:2023 maps to excessive data exposure, but mass assignment is equally critical) occurs when an API endpoint accepts and applies object properties beyond those it should expose to client modification. A user profile update endpoint that accepts a JSON body and applies all properties to the user object may inadvertently accept and apply privileged properties like isAdmin: true or accountBalance: 999999. Testing requires examining the API's data model, identifying privileged or read-only properties, and verifying that the endpoint rejects or ignores unauthorized property modifications.

BOLA is not a single vulnerability but a pattern that must be tested at every endpoint that processes resource identifiers. A systematic BOLA testing methodology requires multiple test accounts and a structured approach to identifier substitution.

The setup phase creates two or more test accounts at different privilege levels: two regular user accounts (User A and User B) and ideally an administrator account. Authenticate each account and capture their session tokens. Create test resources under each account (orders, documents, profiles, messages, or whatever resource types the application manages) and record the resource identifiers associated with each account's resources.

The testing phase attempts horizontal privilege escalation: use User A's session token to request User B's resource identifiers. A vulnerable API returns User B's data. A properly secured API returns HTTP 403. Test every endpoint that accepts a resource identifier: GET (read), PUT/PATCH (modify), DELETE (delete). Read-only BOLA is impactful (data exposure) but modification and deletion BOLA are more severe. Also test vertical privilege escalation: use a regular user's session token to access administrative or system-level resources.

Identifier enumeration is often necessary to construct valid BOLA test cases. Sequential numeric IDs (order ID 1001, 1002, 1003) are the easiest to enumerate. UUIDs are harder but not necessarily safe: if a list endpoint returns resource IDs for the authenticated user and the application also has admin accounts whose UUIDs can be harvested, UUID-based BOLA is still exploitable. Test whether list endpoints for administrative functions expose identifiers of other users' resources, which creates a two-step exploitation path even for UUID-protected resources.

Documenting BOLA findings requires specifying the request (endpoint, method, identifier substituted), the expected response (403 or empty response), and the actual response (data returned or action taken). Business impact assessment should address what data was exposed or what action was permitted: an order IDOR that exposes shipping addresses is a privacy incident; a financial account IDOR that allows balance transfers is a fraud incident. The severity assessment drives remediation priority.

Burp Suite Professional is the standard tool for authenticated API testing. The workflow for API testing differs from web application testing in several ways: API testing requires importing a specification or building a request collection rather than relying on crawler discovery, authentication must be explicitly configured to apply to all test requests, and the testing workflow is more manual and targeted than automated scanning.

Importing an OpenAPI specification into Burp Suite (via the OpenAPI Parser extension or the built-in import in BApp Store versions) creates a structured set of requests corresponding to each documented endpoint. This provides the foundation for systematic testing but does not replace traffic capture: import the spec, then also run the application to capture real traffic, and compare the two to identify endpoints present in traffic but not in the spec.

Authentication configuration for API testing uses Burp's session handling rules or the new Bambdas Java scripting feature in Burp Suite Pro. For JWT-based APIs, create a session handling rule that adds the Authorization: Bearer <token> header to all requests in scope. For APIs that use short-lived tokens, configure a macro that refreshes the token by calling the authentication endpoint and extracts the new token from the response for use in subsequent requests. Getting authentication right before starting testing is critical: a testing session where half the requests are returning 401 because the token expired produces unreliable results and wastes testing time.

For authorization testing, Burp's Autorize extension (available in the BApp Store) automates horizontal privilege escalation testing. Configure Autorize with a second user's session token; it will automatically re-issue every request you make with the second user's credentials and flag responses where the second user receives a 200 response for a resource that should be restricted to the first user. This does not replace manual testing but catches a significant fraction of BOLA vulnerabilities with low additional effort. The Param Miner extension is valuable for discovering undocumented API parameters, which is particularly useful for identifying mass assignment targets.

GraphQL APIs present a different testing surface than REST APIs. The key differences are: GraphQL uses a single endpoint (/graphql) for all operations, the schema is self-describing via introspection, and the query language allows clients to request nested data structures that can cause excessive data exposure and resource consumption issues not possible with REST.

Introspection is the starting point for GraphQL testing. The introspection query enumerates the entire schema including all types, fields, queries, mutations, and subscriptions. Send the following query to enumerate the schema:

{
  __schema {
    types {
      name
      fields {
        name
        type {
          name
        }
      }
    }
  }
}

If introspection is enabled (it should be disabled in production), the response reveals the entire API surface. If introspection is disabled, field suggestion errors ("Did you mean X?") often leak schema information through error messages when querying non-existent fields. Clairvoyance is a tool that exploits field suggestions to reconstruct the schema even when introspection is disabled.

Broken authorization in GraphQL is tested at the field and resolver level rather than the endpoint level. Each field in a GraphQL query may resolve through a different resolver function, and each resolver must independently verify authorization. A user who can query their own profile object should not be able to add the adminNotes field to that query and receive the admin-only data. Test by requesting fields that should be restricted to higher-privilege users and verifying the response returns an authorization error, not the data.

Batching attacks exploit GraphQL's ability to execute multiple operations in a single HTTP request, potentially bypassing rate limiting that operates at the HTTP request level rather than the operation level. If the authentication endpoint accepts batched queries, an attacker can brute-force credentials at a rate determined by the batch size rather than the HTTP request rate limit. Test by sending a batch of mutations or queries and verifying that rate limiting applies to individual operations, not just HTTP requests.

Manual testing covers the vulnerability categories that require contextual judgment (BOLA, business logic, authorization). Automated fuzzing addresses a different category: injection vulnerabilities, unexpected input handling, and error conditions that manual testing typically undercovers due to the breadth of the input space.

OWASP ZAP's API Scan is a command-line-friendly option for automated API security testing against OpenAPI specifications. Invoke it as:

docker run -t ghcr.io/zaproxy/zaproxy:stable zap-api-scan.py \
  -t https://api.example.com/openapi.json \
  -f openapi \
  -r api-scan-report.html

ZAP generates requests for each endpoint defined in the spec, fuzzes input parameters with common injection payloads (SQL injection, command injection, path traversal, XML injection), and reports on responses that indicate vulnerability. The results are most valuable for identifying injection issues and verbose error messages that leak internal details. ZAP's coverage of authorization issues is limited because it cannot reason about the business logic of which user should access which resource.

RESTler is a stateful REST API fuzzer from Microsoft Research that goes beyond ZAP's stateless approach by inferring producer-consumer relationships between API endpoints (a POST to /users that returns a user ID consumed by subsequent requests to /users/{id}) and generating test sequences that exercise the API in realistic ways. RESTler discovers vulnerabilities that stateless fuzzers miss because many API bugs only manifest in specific sequences of operations.

For organizations with CI/CD pipelines, integrating API security testing into the pipeline catches new vulnerabilities at the point of introduction rather than during periodic assessments. A practical pipeline integration: ZAP API scan runs on each pull request against a staging environment, reports new HIGH and CRITICAL findings as blocking checks, and posts the full report as a PR artifact. Manual testing (BOLA, authorization, business logic) runs on a scheduled basis against the production environment or a production-equivalent staging environment.