Yes, but narrowly. Allow or relax your WAF for a labeled DAST run from known source addresses, against a named target, for a set window. Then also run a scan with the WAF fully on. One run tests the application, the other tests the WAF, and you need both answers.
Why the WAF gets in the way
A web application firewall is built to block the traffic a DAST tool produces. Injection strings, odd encodings and fast request bursts all look like an attack, because for the scanner's purposes they are one. If the WAF blocks them, the scanner sees errors or empty pages and records "no finding". That is a false negative caused by the environment, not proof the app is safe.
The opposite mistake is just as common. A team switches the WAF off for the scan, gets a long report, and never learns whether the WAF would have stopped any of it.
Definitions
- Allowlisting: telling the WAF to pass traffic from specific sources without the usual blocking rules.
- Application finding: a weakness in the app itself, visible when the WAF is out of the way.
- Edge control: what the WAF, CDN and rate limiter stop before traffic reaches the app.
How scanners make this easier
Some scanners can label their own traffic. The ZAP documentation, for example, describes a script called AddZapHeader.js that adds a specific header to all traffic passing through it, so that scanner traffic can be identified and WAF exceptions written for it. It also describes an option to add an X-ZAP-Scan-ID request header during active scans. Check your own tool's documentation for the equivalent. A header is a convenience for log filtering and rule writing, not a secret, so never treat it as the only condition for a bypass.
A safe allowlisting plan
- Pick the target. Staging that mirrors production is the usual choice. Name the host and paths.
- Allow by source address first. Run the scanner from fixed addresses and allow those, not a header alone. Anyone can send a header.
- Add the label. Have the scanner tag its traffic so your logs and WAF rules can tell it apart from real users.
- Set a time window. Open the exception when the scan starts and close it when the scan ends. Put the close step in the same job that opens it.
- Keep the rest of the WAF on. Relax only the rule groups that block the scan, and write down which ones.
- Record it. Note who approved the exception, the window and the rule groups touched.
Run both modes
| Run | WAF state | What it tells you |
|---|---|---|
| Scan A | Relaxed for the scanner | Which weaknesses exist in the application |
| Scan B | Fully enforcing | Which of those the edge actually stops |
Compare the two reports. A finding in A that disappears in B is covered by an edge control today, which is useful but fragile: a rule change or a new bypass removes that cover. Fix the application bug anyway and treat the WAF as a second layer, not the repair.
Common mistakes
- Allowlisting a whole network range for months and forgetting it.
- Trusting a custom header as authentication for the exception.
- Reading a clean report from a scan the WAF was quietly blocking. Check the scanner's logs for a spike in 403 or 429 responses.
- Skipping the application owners. A scan against an app behind a bot defense can trigger alerts for the security operations team, so tell them first.
A worked example
Picture a team with a staging site behind a managed WAF and a content delivery network. Their first scan returns three findings and a log full of 403 responses. A quick count shows that 70 percent of the scanner's attack requests were blocked at the edge. The report looks clean because the scanner never reached the application.
The team follows a short routine.
- They ask the network owner for a fixed outbound address for the scanner job.
- They add that address to a temporary allow rule that skips only the injection and protocol rule groups.
- They label the scanner traffic with a header and record the header name in the rule comment.
- They schedule the rule to expire two hours after the scan starts.
- They rerun the scan. The report now has 19 findings, because the scanner reached the code.
- They run a second scan with the exception removed and compare. Six of the 19 findings are blocked at the edge, and 13 are not.
The numbers in this example are illustrative, not data from a real system. The point is the shape of the result: three layers of truth. The first run measured the WAF. The second measured the application. The third measured how much of the application's weakness the WAF covers.
What to tell the people around you
A scan with relaxed edge rules will raise alerts in places you may not expect. Before the first run, notify these groups.
| Group | What they need to know |
|---|---|
| Security operations | Source address, time window, target, and the label on scanner traffic |
| Network or platform team | The temporary rule, its expiry and the rule groups it touches |
| Application owners | What will be tested and how to reach you if something breaks |
| Third-party hosts | Nothing, because the scan should not touch them. If it does, your scope is wrong |
Checks after the scan
- Confirm the temporary rule has been removed and not just disabled.
- Search the WAF logs for the label to see how much scanner traffic was blocked in each mode.
- Review whether the relaxed rule groups were broader than needed, and narrow them next time.
- Add a ticket for each application finding, not for the WAF, since the application bug remains whether or not the edge hides it today.
Bot defenses and rate limits
Many edge services also run bot detection and rate limiting, separate from WAF rules. A scanner may be challenged with a puzzle or slowed down long before a WAF rule fires. Those controls need their own exception, or the scan will stall. Treat each control the same way: a narrow, labeled, time-limited exception, followed by a run with everything on.
When not to allowlist
If the only environment available is production, and the WAF is the main protection, relaxing it for a scan raises real risk. In that case use passive checks, or build a staging copy with the same rules. A test that weakens the thing it is testing is a poor trade.
Where Safeguard fits
This post covers the category in general. For the open source your application ships, Safeguard offers SBOM and dependency scanning with reachability analysis, which no WAF or web scanner can see. You can run a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a scan moves from crawling to testing, then think about which of those requests your WAF would block.
Quick check
Is a custom header enough to bypass the WAF for a scan?
No. Headers are easy to copy. Combine a header with a fixed source address and a time window.
Should the WAF stay off during every scan?
No. Run one scan with the exception and one with the WAF fully on, so you learn about both the app and the edge.
Why do two scans of the same site give different results?
Edge controls such as a WAF, bot defense or rate limiter may block the scanner in one run and not in the other. Compare the logs for blocked requests before trusting either result.
Sources
Last reviewed: 19 October 2026.
