Sometimes during a Web Application scan you may see one of two warnings about the application failing to respond:

• Web application(s) unresponsive ...
• No response from [target web application] in last [time period]

These warnings are related, with similar causes and solutions, but with some important differences.

What the Warnings Mean

Web application(s) unresponsive, so there is nothing to scan

When a web application scan begins the scan process makes its first call to each target application.  If these initial requests all fail (after a number of retries), you will see this warning produced.

You may have configured a single scan with multiple web application scan targets (for example when scanning a Single Page Application you may include both the front end UI and the API).  In a standard scan, where the tickbox "Group URLs" is ticked, all of these scan targets will be scanned together in a single web application scan process.  Therefore, this warning will only be produced if all of those targets were unavailable, at which point the web application scan process will terminate.  If any of the targets are available, the warning will not be produced, and the process will continue scanning the available targets.

It is possible to include multiple web application scan targets in a scan configuration, but have them scanned separately (in separate web application scan processes), by deselecting the option "Group URLs".  In this situation, each separate scan process will check for and potentially emit this warning individually, for its own targets - one process may emit this warning and then terminate, while another process continues scanning its target web application.

The latter situation is unusual, since in most cases if you wish to scan targets separately from each other you would place each target in its own scan configuration.

No response from [target web application] in last [time period]

At the same time as the web application scan process runs, a parallel process runs solely to monitor the availability of the scan target(s).  This process makes a regular request to each scan target.  If the request for any scan target fails consistently for a repeated period of time (as indicated in the warning title), then you will see this warning.

It is possible for some of these monitoring requests to fail (and therefore produce warnings) while others succeed, eg when scanning the front end UI and the API together, and one goes down but not the other.  It is also theoretically possible that the monitoring requests may fail but requests from the actual scan process to other paths (eg paths discovered by crawling) succeed, which would indicate something very specific going wrong in the target web application.

Determining the Cause

The AppCheck scanner does not know the reason that the application was unresponsive.  The scanner is in the same situation as a human end user trying to access a 3rd party website: if the website does not respond the end user does not know why that is, it would need to be investigated on the website side.

That being said, there are some assumptions we can make, or reasonable guesses, based on the behaviour we see.

1. If a target was unresponsive from the very beginning of the scan then it is likely that either the application was completely down, or that access from the Scan Hub's IP address is not permitted through a firewall.

2. If a target was responsive at the beginning of the scan but became unresponsive for a short period, then this suggests that a one-off event occurred, such as a restart of the target application.

3. If a target was responsive at the beginning of the scan but later became unresponsive for a prolonged period, this usually indicates either:

   1. A WAF/IDS device imposing a block on future requests from the scanner's IP address as a response what it sees as malicious traffic;

   2. A service outage, potentially caused by scan saturation (too many concurrent requests) or a scanner request triggering a bug in the application

Determining exactly what the cause of the outage is will usually require accessing logs for the target application (or for WAF/IDS devices that reside between the target and the scanner).

Remediation

The steps for remediation depend on the cause.

• Check that the application URL/domain in the scan configuration is correct.

• Check that the target hostname can be resolved to the correct IP address using public DNS (or see How to Provide Hostname Resolution Without Using Public DNS if you wish to scan a target bypassing public DNS).

• Check that the target application is online and responsive.  If the target has crashed as a result of the scan, this could be caused simply by the load from the scan, or by the scan hitting bugs in the application.  You will need to consult the application logs to ascertain which.
  • If the problem is one of load, you can either increase the resources allocated to your application, or reduce the number of threads the scan runs with (which will reduce the request rate of the scan).  This setting is found at:
    • Scan Settings
      • Web Application Scanner Settings
        • Advanced Settings
          • Max Threads
  • If the problem is caused by a request to a particular path which triggers a crash in the application the long term solution is to update the application to handle that situation without crashing, but in the short term you can instruct that scanner not to request specific paths - see this FAQ for instructions.

• Check for maintenance windows which coincide with the times when the target was unavailable.

• Ensure the scan hub is permitted through any firewalls, WAFs, etc protecting the target application.  See Allowing AppCheck Access to Your Network or Applications.