AppCheck may make tens or hundreds of thousands of requests to a given web application.
The reason for this is can be best explained by digging into how AppCheck works under the hood.
Before AppCheck can test a website for vulnerabilities, it must first build up a map of the site so that it knows what pages need testing for vulnerabilities.
It builds up this map, by default, by a combination of crawling (following links from the root/main page of the site defined in the scan) and by brute forcing (guessing paths that may contain hidden content at common locations such as /admin, or /contact-us. All this involves making a very large number of requests in order to build up the map.
You can reduce the number of calls required in this stage by disabling brute forcing, and by providing a link to a site map, or defining GoScripts to traverse the main flows that you want the scanner to traverse.
Once the scanner has built up its logical map of the site, it has to test each page that it has found. This takes more than one request per page. Imagine that one page on a website has a contact form, something like the below:
You can see that this form has 5 fields that each take input (other forms may well have many more). A scanner plugin such as an XSS (Cross-Site Scripting) check has to try submitting different payloads (entries) into the form fields that can lead to a vulnerability.
Here is a random page that lists various XSS payloads: https://github.com/pgaijin66/XSS-Payloads/blob/master/payload.txt . It has 525 of them, so to check if each of the fields is vulnerable would take 2,625 requests, just for this one plugin on this one page. Its easy to see how the number of page requests can exceed tens of thousands.
Add to that that a request has more than just the form fields: cookies, headers, and that we ignored some of the fields, and that could easily exceed 20K requests for a single form.
You can reduce the number of requests made in this phase by ensuring that only plugins applicable to the site technology are enabled in the scan settings - eg if no Content Management System (CMS) is used, disable CMS checks in the web application plugins settings.
Putting it all together
We can see therefore that a scanner may need to make a very large number of web requests:
Crawling from root - 2000 requests (discovers 200 targets)
Bruteforce Discovery - 2000 requests (discovers additional 75 targets)
Plugin execution of each of the 275 targets x 100 plugins = 27,500 plugin executions.
Payload variation for each plugin = 27,500 plugin executions x 525 payloads per plugin = 1,443,7500 requests
In reality, not every plugin would need to make so many payload executions, but it is easy to see why in combination a large number of requests needs to be made to fully test a site for all vulnerabilities.