Scanning a site behind a WAF

Allowlist Sectora's scanner so it can reach your app for full coverage — instead of being blocked by your own WAF.

If your application sits behind a Web Application Firewall (Cloudflare, AWS WAF, Akamai, Fastly, …), the WAF will often block Sectora's scanner — its requests look like the attacks the WAF is built to stop. When that happens, Sectora can only test the small slice of your app that got through, and the scan reports an advisory like:

Scan coverage incomplete — N% of requests blocked by WAF

Your WAF is real protection (defense in depth) — but a WAF blocking the scanner doesn't tell you whether the app behind it is also secure. WAFs get bypassed or misconfigured, and origin IPs leak, so a vulnerability sitting behind the WAF is still a real risk if that shield is ever down or routed around. Testing the app directly shows your true exposure — so you can fix the root cause, not just rely on the shield.

To get full, accurate coverage of your own application, allowlist Sectora's scannerso its traffic reaches your app while everyone else's is still filtered.

Recommended: allowlist Sectora's scanner IP

Every Sectora DAST scan — staging and production — egresses from a single, stable IP address:

Sectora scanner IP:  34.140.185.121

You can always find the current value in your dashboard under Settings → Scanning, or ask support. We notify customers in advance of any change.

Add an allow rule for that IP in your WAF. This is the cleanest approach — there's no shared secret to manage, and it's the same pattern every major scanner uses.

Cloudflare

Security → WAF → Custom rules → Create rule.
Field IP Source Address equals 34.140.185.121.
Action: Skip → select the components to skip (Managed Rules, Rate Limiting, Bot Fight Mode). Skipping only what's needed (rather than "Allow all") keeps the rule tight.
Deploy. (Optionally enable it only for the duration of a scan.)

You can also add the IP to Security → Tools → IP Access Rules as Allow, scoped to the specific zone.

AWS WAF

Create an IP set containing 34.140.185.121/32.
In your Web ACL, add a rule that Allows requests matching that IP set, and place it above your blocking rules (Web ACL rules are evaluated in order; the first match wins).

Akamai

Add 34.140.185.121 to a Network List, then reference it in an exceptionon the relevant security policy (Kona / App & API Protector) so matching traffic bypasses the rate and attack controls.

Generic firewall / API gateway

Allow inbound traffic from 34.140.185.121 ahead of any IP-reputation or attack filtering. The scanner only ever connects to the target you configured.

Can't allowlist by IP?

Some setups can't match on source IP (for example, a WAF sitting behind a CDN that hides the original client IP). If that's you, contact support — we can issue a per-account secret token that Sectora sends as a request header, which you allowlist with a single rule (skip WAF if header X-Sectora-Scan = <secret>).

If you set up a header rule yourself, it must match a secret value, never just the header's presence. A rule like "skip the WAF if header X-Sectora-Scanexists" is a one-line bypass for any attacker who adds the header — use a long, random, rotatable secret, and ideally combine it with the scanner IP above.

After allowlisting

Re-run the scan. The "coverage incomplete" advisory should disappear, and you'll see the full set of findings for your authenticated API surface — IDOR/BOLA, broken access control, injection — instead of just the slice that slipped past the WAF. Fix those at the application level and keep the WAF as defense-in-depth. For the authenticated/gray-box setup itself, see Authenticated Scanning.