Analyze Logs

API: Logs¶

Coverage analysis provides:

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

Reading the Logs Status¶

Each endpoint (or GraphQL operation) in the Scan Logs returns one of these statuses:

• UNAUTHORIZED: All requests sent to the endpoint came back with an authentication or authorization error message.
• RATE LIMITED: All requests sent to the endpoint came back with a rate limit error message.
• SERVER ERROR: All requests sent to the endpoint came back with a server error message.
• REDIRECTED: All requests sent to the endpoint came back with a redirection error message.
• NOT FOUND: All requests sent to the endpoint came back with a "not found" error message, although it is defined in the schema provided for the scan.
• OK: At least one request sent to the endpoint does not fall into one of the previous categories.
• BLACKLISTED: The endpoint has been blacklisted in the configuration. No request has been sent to it.
• SKIPPED: The endpoint is not blacklisted, but still no request has been sent to the endpoint.

How Is Coverage Computed?¶

Coverage is calculated using the following formula:

Example:

If you have a GraphQL API with 5 queries and 5 mutations, the total number of endpoints is 10. If two of the queries are UNAUTHORIZED and the rest is OK.

• With a read and write scan, the coverage would be 8/10 = 80%.
• With a read-only scan, the coverage would be 3/5 = 60% (in this scan the mutations will be blacklisted).

How to Improve Your Coverage?¶

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

Set Scan Type to Staging (Read & Write)¶

A Product (Read-Only) scan keeps your application safe. It does not perform thorough security tests that could damage your database or infrastructure. In particular, it blacklists all data-mutating endpoints.

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

Handle Redirections with Private Locations¶

For security reasons, Escape only follows redirection using Private Locations:

• Use Private Locations to handle redirection securely
• Update schema to match actual endpoint paths
• See Private Locations documentation

If you see a lot of redirection errors, it can be a sign that your endpoint or your schema is not perfectly configured.

For security reasons, Escape only follows redirection using Private Locations.

For example if you see a redirection for the /user route to /user/, you may want to update your schema to reflect this change.

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 infered 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 blacklisting the problematic endpoints can help.

Make Sure the Scan Is Not Rate Limited¶

If your application (or a firewall in front of it) implements rate limiting, you may want to relate that in the scan configuration.

Scans can be slowed down using rate-limiting configuration, though it may impact the scan duration.

SPA: Visited Pages¶

The Visited Pages is also an important part of your scan results. Contrary to API Scans, the scanner does not have a predefined list of endpoints, so it's scanning is based on a crawling system, and a security checks engine. This way you can validate the pages that were visited and the issues found on each page.