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.

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.