Skip to content

WebApp Testing: API Coverage

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

This page explains what API Coverage proves, how to read a successful capture, and where to debug endpoints that were captured but not actively tested.

Captured Doesn't Mean Tested

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.

A request can therefore be captured and successful (HTTP 200) without ever being actively tested. This is by design: the filters exist to keep scans fast, safe, and focused on meaningful attack surface.

Why does this matter?

An endpoint visible in the API Coverage logs with a 200 response is evidence that the scanner reached the endpoint. The absence of security-check activity on that endpoint isn't a bug by itself. It means the request didn't pass one of the selection filters.

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.