Skip to content

WebApp Testing: API Coverage

During a WebApp scan, the browser engine captures every API request the application issues while it's being crawled. The API Coverage view lists these requests and shows, per endpoint, which security checks were executed against them.

Use API Coverage to review successful captures and security-check activity, then diagnose test selection for the endpoints you want to assess.

Capture and Active Testing

WebApp Testing splits API handling into two distinct phases:

  1. Capture: The browser observes an API request while navigating the application. The raw request/response is recorded and appears in the API Coverage logs (this is what produces the 200 entries you see in the coverage view).
  2. Active testing: After capture, the request is passed through a series of filters. Only requests that survive every filter are sent to the security-check engine for active fuzzing, including injection payloads, IDOR, and mass-assignment checks.

Capture status shows the outcome of the browser request. Security-check activity shows the active tests run against that request. Selection filters apply your scope, scan mode, and check configuration before active testing.

Why Does This Matter?

A 200 response confirms that the browser reached the endpoint successfully. Review security-check activity separately to confirm active testing. Use Test Selection to check scope, enabled checks, scan duration, and other selection criteria.

What API Coverage Shows

The API Coverage view is the source of truth for captured API traffic during a WebApp scan. Use it to confirm:

  • Which API requests the browser issued while crawling the application
  • Which HTTP method, URL, status code, request body, and response body were recorded for each exchange
  • Whether an exchange was only captured or also exercised by active security checks
  • Whether repeated traffic, authentication traffic, or out-of-scope traffic reached the application

The view can contain requests that the scanner intentionally skipped for active testing. For example, a blocklisted endpoint may still appear because the application itself called it from the browser during normal rendering.

Protocols Covered

The browser captures traffic at the network layer, so anything the application speaks over HTTP during the crawl lands in API Coverage. What Escape then does with each exchange depends on the protocol.

Protocol What the Scan Does
REST over HTTP (JSON) Captured as XHR or fetch, turned into REST templates, and actively fuzzed by the same engine as API Testing (injection, BOLA/IDOR, mass assignment). These exchanges also feed the auto-generated OpenAPI spec.
Form submissions (application/x-www-form-urlencoded) Same pipeline as REST. Included in the generated OpenAPI spec.
GraphQL over HTTP Recognized from a /graphql path or a GraphQL-shaped body. Queries and mutations are fuzzed with the GraphQL check suite. Persisted queries (extensions.persistedQuery) are handled. See GraphQL.
Multipart uploads (multipart/form-data) Routed to the file upload testing pipeline. See File Upload Testing.
WebSocket (ws:// / wss://) Every connection the page opens is observed, reported as a WebSocket API Service asset, and checked for insecure transport. See Insecure WebSocket Connection.
gRPC-Web Recognized on grpc/ paths, reported as a gRPC API Service asset, and linked back to the web app that calls it.
MCP over HTTP Model Context Protocol servers the application reaches are checked for unauthenticated access.

Captured REST and GraphQL traffic uses the same check engine as a dedicated REST or GraphQL API scan, so you get the same checks without a separate API profile.

When to Debug Test Selection

Open Test Selection when an endpoint:

  • Appears in API Coverage with a successful response
  • Has no active security-check activity
  • Matters for the attack surface you expected the scan to test

The Test Selection page lists each deterministic filter that can keep a captured endpoint out of the active-testing pipeline.