NOTE: You may be directed to this page when you see the warnings "Web application(s) unresponsive". That is because the causes and solution are the same.
Sometimes a scan will report Warnings on the scan results page stating that there were one or more failed responses from the scanned web application:
Typically, this means either that the application in question was completely unreachable (if these warnings are seen throughout the scan), or that it became unresponsive at least once for a period during the scan window (if the warning was only seen during a certain period of the scan).
How The Check Works
During web application scanning, the scan hub, in parallel to the scanning, performs a check every 60 seconds as to the availability of the web application. The application makes an HTTP GET request to the default path (usually "/") defined for the the target web application. If this request does not return an HTTP response within a 30-second period, the scan hub logs the check internally as having failed. If 30 of these every-minute checks fail consecutively (without any successful request being made in between by the healthcheck poller), then it logs the warning message. Other requests by the scanner *may* have successfully reached the target server during this period,
NOTE: The AppCheck scanner does not know the reason that the application was unresponsive. Consider this like when an end user tries try to access a 3rd party website; if the website does not respond the end user does not know why that is, as they have no further information regarding the state of that website. This needs to be investigation on the application side.
If the endpoint was unresponsive for the entire duration of the scan and no successful responses were seen and no web app vulnerabilities found, then it is likely that the application was permanently either completely down, or that access from the scanhub's IP address is not permitted through a firewall.
If the failed response was a one-off, then this suggests that the web application stopped responding at some point during scanning due to one-off events such as service restarts (eg for log rotation).
If the failed responses were for prolonged periods, then this can be due to
Interference by a WAF/IDS device blocking the scanner's requests.
Service outages, potentially caused by scan saturation (too many concurrent requests)
Permanently Unreachable Endpoints
Check that the application URL/domain provided is correct and populated in public DNS.
Confirm that the scan hub is permitted through any firewalls protecting the target application. For AppCheck's public scan hubs you can find the IP Addresses here; for internal scans you will need to use the IP address of your private scan hub.
Intermittently Unavailable Endpoints
If the service became unavailable once or a handful of times only, confirm if this matches some known maintenance window or log rotation period where the service may be down.
If the service became available multiple times, or consistently throughout the scan run, then it is probable that either:
There is an application-layer filtering device such as a Web Application Firewall (WAF), Network Intrusion Detection System (IDS), or Traffic Manager/Application Delivery Controller (ADC) that is either filtering, throttling or denying requests from the AppCheck scan hubs. See Allowing AppCheck Access to Your Network or Applications.
The AppCheck scan intensity is set too high and the contention from scanning is causing service impact. If this is suspected, the scan settings for the scan should be amended to significantly reduce the scan intensity (eg by a factor of two) under
-> Web Application Scanner Settings
-> Advanced Settings
-> Max Threads
Note that scan duration will increase if scan intensity is decreased - halving the scan intensity will (roughly) double the scan duration, and this may impact on permitted scan schedule windows. For more information on reducing the risk from scanning, see our FAQ on this subject.
Please sign in to leave a comment.