How can I see a list of which paths or URLs AppCheck has scanned (crawled and attacked) for my web application?

Background Information

AppCheck performs two broad phases of scanning at the top-level:

1. Crawling a target to navigate through it and find links to other pages, building up a site map or map of the site.
2. Attacking in which attack payloads are launched against the mapped attack surface (a subset of pages found via crawling and other techniques such as brute force discovery)

(For a detailed summary of crawl operation, see our article at https://appcheck.zendesk.com/hc/en-us/articles/360033942613 )

The article below explains why the crawled site map and the mapped attack surface are not equivalent.

AppCheck Behaviour

You can see a list of logical attack paths at:

1. Scan Results
   1. By Impact
      1. Info
         1. Mapped Attack Surface
            1. Mapped Attack Surface
               1. Details

This is not however a list of every page crawled, it is the de-duplicated list of paths believed to map to unique back-end page generation/application code.

It is important to note that AppCheck NG will not necessarily scan every single page on your web application, even if it discovers it during a crawl phase. This is by design, because web applications are largely dynamic in the modern era, and URLs rarely map to unique content but are generated on demand by a single controller in the code.

For example, on Amazon's website there is a URL https://www.amazon.co.uk/Ankoda-iPhone-Charger-Lightning-Compatible/dp/B07NVJJ3G8/ - however there will be a similar URL for each product in Amazon's product catalogue - the catalogue containers around 564 million products, but the application code for serving all of them is in a single codebase file for product pages - hence any application code vulnerability will express on any one of the product pages and a single page can be scanned rather than all 564 million, massively reducing the time taken to scan a site. This is especially important since pages scanned must be "fuzzed", with AppCheck making thousands of subtly tweaked requests to the same page to probe for weaknesses in different parameters, or of different types. 

However, since scanning is performed in a "black box" state in which AppCheck has no direct insight into the code running on the server, it has to make educated guesses about how many controllers there are and at which paths, and hence which pages are necessary to be scanned in order to prevent scanning of duplicate controllers whilst ensuring full coverage. This can be a complex problem.

What you can do if mapped attack surface is incomplete

If you can see that a page that definitely is generated by a unique controller is not currently in your mapped attack surface for a scan, you have the option to manually add it to ensure that it is scanned. This adds one or more paths to the list of paths for scanning and is concatenated to the output of paths found from other methods such as brute force discovery, page crawling etc. This option can be found in Settings -> Web Application Scanner Settings -> Advanced Settings -> Seeded Targets

Seeded targets will both be crawled (to discover other pages they link to) and be used as an attack target (ie have attack payloads launched against them). They are not de-duplicated as other pages found via crawling are. It is therefore important to remember that adding an excessive number of seeded targets may cause the length of time for a scan to complete to increase substantially.