Modern firewalls, Intrusion Prevention Systems (IPS), Web Application Firewalls (WAF) and other such systems can be configured to persistently ban, block or rate-limit requests from specific IP addresses, or deny or rate limit all requests except those coming from specific IP addresses (or indeed a combination of both approaches).

Your system may take a default-deny approach, where any IP address not in the allow-list is denied access; or a default-allow list where any IP address not in the deny-list is allowed access.  In a default-allow system, if an IP address is flagged as making malicious requests then it will be added to the deny list, either temporarily or permanently.

An allow-list ensures that requests from the specified IP addresses are allowed through in both cases, even if the address is seen to make malicious requests.

It is also possible to have both such systems in place - for example you may have a primary allow-list which lists the only IP addresses allowed to make requests, but even addresses on that list may be added to a deny-list and blocked if they are seen to make malicious requests.  In this case you may find you have a second allow-list, which lists IP addresses which should be excused from the deny-list (even if they make malicious looking requests).

An example request might first hit your firewall which takes a default-deny approach.  The request is in the firewall's allow-list and so is allowed through.  The request is then evaluated by your WAF and found to be malicious, and is therefore blocked.  The WAF also adds the source IP address to its deny-list for 1 hour, meaning all further requests from that address are blocked by the WAF for one hour, even though they are in the firewall's allow-list.  To ensure the requests are allowed through, the address must be in the firewall's allow list and the WAF's allow-list.

CDNs and DDOS mitigation tools like Cloudflare often do something similar and have their own allow-lists (sometimes more than one).

1. How this affects AppCheck scans
2. How to ensure AppCheck's access
3. Why AppCheck should allowed through
4. Doesn't this make it an unfair test?
5. Can AppCheck be Used to Test the Effectiveness of my Intrusion Prevention System?
6. AppCheck's IP Address

How this affects AppCheck scans

To test for vulnerabilities AppCheck sends requests that resemble attacks (albeit harmless versions of attacks), and it sends a great number of requests, so any WAF/IPS will flag AppCheck as a risk for both those reasons.  If AppCheck is not on the WAF/IPS's allow-list then this will result in further requests from AppCheck being blocked or modified, thus preventing the scan from completing successfully.

Usually AppCheck is able to detect such behaviour, and you will see a finding in the scan results called "Scan Interference", which shows the behaviour that the scanner thinks indicates a WAF/IPS blocking requests.  However, due to the varied forms such blocking can take, it is possible for a system to block AppCheck's requests without the scanner detecting it.  In such a case your scan results would likely be incomplete, and vulnerabilities in your application could go undetected, with no warning in the scan results.  It is therefore a sensible precaution to confirm the presence of such systems, and that AppCheck is allowed access, before running scans.

How to ensure AppCheck's access

There are two approaches that can be taken to ensure the scanner's requests are not blocked.

1. Bypass WAFs/IPSs entirely, running scans against the origin server
2. Adding AppCheck's IP address to allow-list for every system that might block requests

Bypass WAFs/IPSs entirely, running scans against the origin server

The simplest way to ensure a WAF/IPS does not block Appcheck's requests is to bypass that system, and scan an upstream server (such as your web server or app server) directly.  The upstream server you target this way is known as the origin server.

For example, if your domain name resolves to 198.51.100.13, which is the IP address of your WAF, and the public IP address of your origin server is 203.0.113.69, you could bypass the WAF by configuring your scan to target 203.0.113.69 instead.

This could be as simple as changing the scan target from https://example.com/ to https://203.0.113.69/.  However, most origin servers will reject such requests, as they expect requests to target a particular host name.  In that situation, you can leave the scan target as https://example.com/, but tell the scanner to ignore public DNS records and instead resolve example.com to 203.0.113.69.  That way requests from the scanner will arrive directly at your origin server, bypassing the WAF, but with the correct host header.

See How to Provide Hostname Resolution Without Using Public DNS for a guide to configuring this.

It's likely that the origin server does not normally receive requests directly from the internet (since traffic normally goes via the downstream server, the WAF/IPS that we are bypassing), so it is probable that a firewall rule will be required to allow requests from AppCheck through to the origin server.

Adding AppCheck's IP address to allow-list for every system that might block requests

Instructions for adding AppCheck's IP ranges to allow-lists will be specific to the system in question - consult the system's own documentation.

Remember that you may have multiple systems, each with their own allow-list(s); AppCheck's IP address will need to be in the allow-list for each system involved.

We have found that due to complexity of the some products it can be difficult to ensure you have updated every applicable allow-list.  For example, users of CloudFlare have often found the scanner's requests are blocked even after adding Appcheck's IP ranges to what they believe are all the applicable allow-lists.  Consequently, we recommend the bypassing method described above.

Why AppCheck should be allowed through

AppCheck needs access to your application and infrastructure to scan them, so access through firewalls is of course essential.

AppCheck scans involve a huge number of requests, well into the tens or hundreds of thousands.  The request volume alone is also likely to trigger blocks.  Even if this behaviour results not in full blocks but in rate-limiting, the time taken for the scan may go from hours to weeks.

To detect and confirm the presence of vulnerabilities AppCheck makes malicious looking attacks which simulate real attacks, albeit in a harmless manner.   Any IPS/WAF that sees AppCheck's requests will block them if not instructed otherwise.

If AppCheck's requests are blocked it cannot detect vulnerabilities.  Furthermore, since blocks are often imposed for a period of time (or indefinitely) after an attack is detected, it is not just the vulnerability that was being probed for when the block was triggered that goes undetected; rather the rest of the scan will be missing results.

Doesn't bypassing defences make it an unfair test?

AppCheck aims to detect as many security flaws as possible, safely and accurately. The aim of a vulnerability scan is not to test the scanner's ability to model a malicious attack, or to bypass mitigation systems like IPS and WAFs, but rather to detect as many vulnerabilities in the underlying application as possible, in order that they may be fixed before being exploited

AppCheck makes a large number of apparent attacks in a short period of time, and makes no attempt to conceal itself or to fool your IPS/WAF, and so will be easily detected.  An actual attacker however would likely make a far smaller number of highly targeted requests, which is much harder to detect, and they may well take steps to fool or bypass your IPS/WAF.  If they succeed they would have access to your application in a way AppCheck did not and would be able to exploit vulnerabilities of which you were unaware.

Can AppCheck be Used to Test the Effectiveness of my Intrusion Prevention System?

AppCheck, like all vulnerability scanners, will trigger IPS rules. There are several approaches that can be adopted to test the IPS as well as the target applications and systems.

A common approach is to run two scans, one with where AppCheck's requests will not be blocked by the IPS, and one where they will (for example, one targeting the origin server directly, and one targeting the WAF/IPS).  If you see vulnerabilities in the origin server scan but not in the other, then this suggests the IPS/WAF is offering some protection against exploitation of that vulnerability (but see the previous section for why this is not necessarily adequate protection).

AppCheck's IP Address

An up-to-date list is maintained in the following FAQ: AppCheck's IP Range