Skip to content

Analyze Coverage

API Coverage

Coverage analysis provides:

  • Transparency: Full visibility of scan execution, with logging of each request
  • Actionability: Step-by-step recommendations for optimal scan configuration

Looking at API Coverage for a WebApp (Frontend) Scan?

The coverage view for WebApp scans lists every API request the browser captured while crawling the application. Review capture status to confirm which endpoints the browser reached, and security-check activity to confirm which requests were actively tested. Authentication requests, duplicate exchanges, and endpoints outside the API testing scope can appear as successful (200) captures with no active tests. See WebApp Testing: API Coverage and WebApp Testing: Test Selection for selection rules and a diagnostic checklist.

Automation Via the Public API

For CI/CD or other automation, you can retrieve the same aggregate and per-endpoint coverage data over the REST Public API (scan coverage, and GET /v3/scans/{scanId}/targets for endpoint-level fields). See Public API: Retrieving API coverage in CI/CD.

Reading the Coverage Status

Endpoint and GraphQL operation coverage uses the following statuses. BLOCKLISTED and SKIPPED indicate that no request was sent to the target:

  • UNAUTHORIZED: All requests sent to the endpoint came back with an authentication or authorization error message.
  • RATE_LIMIT (Rate Limit): All requests sent to the endpoint came back with a rate limit error message.
  • SERVER_ERROR (Server Error): All requests sent to the endpoint came back with a server error message.
  • REDIRECTION (Redirection): All requests sent to the endpoint came back with a redirection error message.
  • NOT_FOUND (Not Found): All requests sent to the endpoint came back with a "not found" error message, although it's defined in the schema provided for the scan. A common cause on REST scans is a duplicated base path: the asset URL already ends with /api or /v1 while every OpenAPI path starts with the same prefix, so the scanner calls /api/api/.... Look for Possible duplicated API base path or Possible API base path mismatch in validation events, then point the asset URL at the origin (without the overlapping suffix) or remove that prefix from the spec.
  • OK: At least one request sent to the endpoint doesn't fall into one of the error categories.
  • TIMEOUT (Timeout): A request timed out.
  • VALIDATION_ERROR (Validation Error): A request failed validation.
  • REPEATER_ERROR (Repeater Error): A proxy or Location error prevented the request.
  • BROKEN_PIPE (Broken Pipe): The connection broke while sending a request.
  • UNKNOWN (Unknown): The response classification is unknown.
  • BLOCKLISTED: The endpoint has been blocklisted in the configuration. No request has been sent to it.
  • SKIPPED: The endpoint isn't blocklisted, but still no request has been sent to the endpoint.

Error Message Classification

Error classification goes beyond HTTP Status Codes. For example, GraphQL applications often return 200 even for errors. Escape AI intelligently classifies responses based on their content and context.

Why Are Some of My Endpoints SKIPPED

The two most common reasons are:

  1. Server stopped responding (scan stopped early) - check scan results for issues
  2. Speed-focused scan mode selected - consider changing mode for more thorough results

About the BLOCKLISTED Operations

Read-only scans exclude operations that the scanner classifies as data-mutating. For GraphQL, this excludes mutations. Review API Scope for additional exclusions.

How Is Coverage Computed?

The endpoints-covered dashboard counts targets with OK or UNKNOWN coverage as covered. For WebApp scans, capture coverage shows which endpoints the browser reached; security-check activity shows which requests were actively tested. See WebApp API Coverage.

How to Improve Your Coverage?

After your first scan, check the Coverage panel to analyze your application coverage. Here are key ways to improve coverage:

Review Read-Only Mode

Read-only mode focuses API checks on operations classified as reads. Use read-write mode when your environment permits testing data-mutating operations. See Production-Safe Scanning for browser behavior and safety settings.

Provide Sufficient Authorization

  • Configure authentication for endpoints showing UNAUTHORIZED errors
  • Verify token validity by testing with provided curl commands
  • See Authentication for setup details

Maintain Schema Quality

  • Provide up-to-date schemas following current standards
  • Remove deprecated endpoints to improve coverage calculation
  • Update schema to reflect current endpoint structure
  • Keep the REST asset URL and spec paths from overlapping. The scanner concatenates them (asset URL + spec path). If both include /api or /v1, coverage fills with NOT FOUND on doubled paths. Drop the shared prefix from one side.

Check Redirections

If /user redirects to /user/, update the schema to match the actual endpoint path. Review redirection responses to check whether authentication or the API URL needs adjustment.

Ensure Your Server Remains Reachable During the Scan

The scan is intense and attempts complex attack scenarios. In some cases, this will make the server unreachable for a few dozen seconds, causing the scan to stop early.

By looking at the inferred status code over time or your internal monitoring, you can see if the server has been unreachable during the scan. Making your application more resilient or blocklisting the problematic endpoints can help.

Make Sure the Scan Is Not Rate Limited

Match the scan's request rate to your application or firewall's rate limits using rate-limiting configuration. A lower request rate can increase scan duration.