
We reworked how Escape represents dynamic security testing tool coverage across web applications and APIs, with one goal:
Make every executed action observable, verifiable, and explainable. We strongly believe every app is different, and just showing visited URLs is not enough.
After every security scan, you might be left wondering: "Did it actually test our admin endpoints? How did it reach that nested API call? Why didn't it find the vulnerability our pentester discovered?" When auditors, developers, or leadership ask for proof of thorough testing, you're stuck with a vulnerability report and a shrug.

Now, we help your team to answer the following questions:
This update makes Escape’s exploration and testing fully transparent, end-to-end. You can prove what was tested, troubleshoot gaps instantly, and stop defending your security tooling.
Yes, you can now get full visibility into everything executed during a scan and truly check whether Escape is testing your applications and APIs appropriately.
Find more details on each point below.
The API Coverage page shows every API endpoint visited by the crawler, allowing you to quickly confirm that sensitive routes were actually exercised.

You can:
This lets you answer, with certainty:
Was this endpoint actually exercised during the scan?
You can narrow the list of endpoints by:
This is especially useful to:
At the top of the page, Escape visualizes HTTP status codes (200 / 400 / 500 …) in a stacked bar chart. This gives you a fast signal for questions like “Are a large number of endpoints returning 400 or 500?”
The coverage page tells you what was reached. Attack Path Validation Graphs show how it was reached, including the initial input. For each endpoint, you can open an Attack Path Validation Graph that exposes the exact execution chain used by Escape to get there.
💡
These graphs help you to understand complete request sequence generated by Escape’s Business Logic Security Testing (BLST) algorithm, an intelligent engine built by the our research team that understands dependencies, extracts dynamic values, and chains requests like an experienced pentester.
Each graph represents:
Extractions and reinjections between different requests are described using jq syntax.

Imagine an API exposing:
GET /books/v1→ returns a list of books and associated user_idGET /users/v1/{user_id}→ returns user detailsDuring exploration:
GET /books/v1user_id values from the responseGET /users/v1/{user_id}In the Attack Path Validation Graph, you can see:
To complement raw execution data, Escape adds AI pentesting summaries per endpoint.
Exploration Summary (Beta)
This explains the endpoint's purpose, business logic, how it was discovered, and which execution path led to it. It is particularly useful for reviews, knowledge transfer, audits.
Pentesting Summary (Beta)
This section focuses on security impact and provides explanations:
It connects findings directly to execution evidence.
To get access to the AI pentesting summary feature, reach out to your dedicated Escape contact.
Escape now shows:
Every unique application state reached during the crawl is:

Beyond screenshot validation, Escape delivers AI-generated summaries that break down how vulnerabilities associated with a specific page were uncovered and precisely which attack attempts led to its discovery:

In a dedicated tab, you can view all issues linked to this specific web page, giving you immediate visibility into what was found and where.

No more guessing whether a given page was touched during scanning.
💡
Behind the scenes: Escape’s RL-driven web crawler identifies similar page states and avoids redundant visits — now you can see exactly which unique states were tested and why.

A structured list of all discovered pages organized by folder and hierarchy. This makes it easy to:
When web crawling triggers API calls (XHR/Fetch), those same coverage and attack path visualisation capabilities apply — giving you:
This gives you end-to-end visibility, from UI action → API call → vulnerability.

With this release, Escape shifts dynamic testing from a black box to a glass box.
You don’t just see results of the scan, you see:
Whether you’re validating that a critical part of a web app was tested, debugging a failed scan, preparing for an audit, or reviewing a production incident, Escape gives you the right evidence.
Escape’s improved Logs page gives you a complete, chronological view of everything that happens during a scan — and, crucially, why it happens.
By making every scanner decision, skip, and failure fully visible, Logs help you quickly diagnose issues, fine-tune configurations, and continuously improve scan coverage and reliability.
The result: less guesswork, faster debugging, and better scans over time.
What you’ll see in the Logs page
The Logs page shows every event associated with a scan, including:

It helps to answer the following questions like
You can search and filter logs by:
to help you troubleshoot scan problems instantly:
Each log entry is evidence-backed:

or screenshots captured via Agentic crawling:

You can even save filtered views to reuse during reviews or audits.
Feel free to explore!
Want to improve your current coverage? Check out our documentation.
💡 Want to get more out of Escape? Explore these guides to optimize your workflows, save time, and make your agentic pentesting or DAST tool even more efficient:
*** This is a Security Bloggers Network syndicated blog from Escape - Application Security & Offensive Security Blog authored by Alexandra Charikova. Read the original post at: https://escape.tech/blog/how-to-visualize-coverage-and-validate-attack-paths/