Let the scan through your WAF

A WAF, bot control or rate limit that blocks or challenges the scan stops its attack requests before they reach your application. The vulnerabilities behind it go untested. Allow Interopt's addresses, and only those, through each control in front of the target, and keep every control on for everyone else.

What to allow

• Interopt's addresses. The New scan form lists them under Before you start → Allowlist scanner traffic. See Scanner IP addresses. They are IPv4 addresses; the scan doesn't connect over IPv6. Allow every address listed, and compare the list with your rule before a scan, since it can grow.
• The connecting address. Match the address the WAF sees the connection come from, not X-Forwarded-For or a similar header. Anyone can set those headers, and the scan may send its own values in them when it tests how your application trusts them.
• Only the hosts in scope. Limit the rule to the target's hostname, plus any API host, hosts named under Only test, and hosts you select under Other hosts. Testers send attack requests to all of them.
• Ahead of everything else. Put the rule before your managed rules, bot rules and rate limits. A rule lower in the order never runs for a request an earlier rule already blocked.
• Every control that can block or challenge. Managed WAF rules, bot protection, JavaScript or CAPTCHA challenges, rate limits and IP reputation each stop a scan on their own.

Don't switch a control off for everyone to let the scan through. Where a staging copy runs the same WAF configuration as production, scan that, and add the rule there. For one scan, remove the rule once the scan has finished. If the asset has scheduled scans or you retest findings, keep the rule, or turn it on before each run.

A WAF exception keyed on a header or cookie you add under Extra headers or cookies doesn't cover the check the scan makes while preparing, so allow by address.

What the scan checks first

On a white-box scan of a URL you supply, the Preparing stage ends with "Checking the running application". It requests your start page and a path that doesn't exist, each once as is and once with a harmless attack string in an interopt_probe query parameter. The scan also reads headers, cookies and server names that identify a CDN or WAF, such as Cloudflare, AWS WAF, Akamai, Imperva or Azure Front Door.

• The attack string is blocked and the plain request isn't: the scan pauses before testing starts. Its reason begins "A WAF in front of", followed by your URL, the WAF's name when it was recognized, and the responses it got, such as "HTTP 403 with a block page". Add the rule, then select Resume scan; it continues where it stopped. While a scan is paused in Preparing, cancelling it returns its credits.
• A CDN or WAF is recognized but doesn't block: testing starts. A test the WAF stops later doesn't clear a finding. The finding keeps its verdict from the code, with a note that the live test was blocked by a WAF.
• Every request is challenged or blocked, with or without the attack string: the scan doesn't pause, but testers can't get past the challenge either. Allow the addresses before starting.
• The start page starts returning a block mid-scan, such as after a rate limit or an automatic ban: the scan pauses with a reason that begins "A WAF in front of the instance now blocks". Allow the addresses through the control that banned them, then resume.

A scan paused on your side that isn't resumed within 7 days fails.

Cloudflare

Cloudflare's own guides: custom rules, the Skip action and IP lists.

(ip.src in $interopt_scanner and http.host in {"app.example.com" "api.example.com"})

• Bot Fight Mode, on the Free plan, can't be skipped by a custom rule. Cloudflare doesn't apply it to a request an IP Access rule with the Allow action matches first, so add one per address. An IP Access rule covers the whole zone, so remove it after the scan.
• Cloudflare Access: when the application sits behind Access, add a policy to its Access application with the Bypass action and an Include rule on IP ranges with Interopt's addresses. Cloudflare doesn't log requests a Bypass policy lets through. See Access policies.

AWS WAF

AWS's own guides: IP sets, IP set match statements and rule priority.

With Shield Advanced automatic application layer DDoS mitigation, Shield adds its rule group at priority 10,000,000, after your rules. An Allow rule above it lets the addresses through. See Shield's rule group.

Azure Front Door

Microsoft's own guides: custom rules and IP rules.

Allow stops evaluation, so managed rule sets, the bot manager rule set included, don't run for a matching request. SocketAddr is the address that connected to Front Door; RemoteAddr can come from X-Forwarded-For.

The same rule with the Azure CLI:

az network front-door waf-policy rule create \
  --resource-group <resource-group> --policy-name <policy> \
  --name AllowInteropt --priority 1 --rule-type MatchRule --action Allow --defer
az network front-door waf-policy rule match-condition add \
  --resource-group <resource-group> --policy-name <policy> --name AllowInteropt \
  --match-variable SocketAddr --operator IPMatch --values <address-1> <address-2>

Azure Application Gateway

Microsoft's own guides: custom rules and examples.

Allow skips every later custom rule and the managed rule sets. With Front Door in front of the gateway, add the rule on Front Door: the gateway then sees Front Door's addresses.

Google Cloud Armor

Google's own guide: security policy rules.

Evaluation stops at the first matching rule, so a lower-numbered Allow rule also takes precedence over rules Adaptive Protection deploys. With gcloud:

gcloud compute security-policies rules create 100 \
  --security-policy <policy> \
  --description "Interopt scan" \
  --src-ip-ranges "<address-1>","<address-2>" \
  --action allow

Akamai App & API Protector

Akamai's references: bypass network lists and client lists in a match target.

Rate controls and Bot Manager decide on their own. Once the scan is testing, check Web Security Analytics for requests from the list that rate controls or Bot Manager denied, and add an exception for the list in that control.

Fastly Next-Gen WAF

Fastly's own guides: lists and request rules.

Allow takes precedence over block rules, account rules included. Advanced rate limiting rules can't use Allow, so add the condition IP address Is not in list to each one that could count the scan.

Imperva Cloud WAF

Imperva's own guide: policies.

Allowlisted addresses bypass every security policy on those sites. For a narrower exception, add the addresses as an exception to the WAF Rules policy instead; the site's other policies then still apply to them and can still stop the scan.

F5 BIG-IP Advanced WAF

F5's own guide: IP address exceptions.

A bot defense or DoS profile on the virtual server has its own allowlist; add the addresses there too.

F5 WAF for NGINX

F5's own guide: IP address lists. Formerly NGINX App Protect WAF.

Add a list whose requests are never blocked to the policy, then reload NGINX, or recompile the policy bundle on deployments that compile policies:

{
  "policy": {
    "name": "app_policy",
    "template": { "name": "POLICY_TEMPLATE_NGINX_BASE" },
    "enforcementMode": "blocking",
    "ip-address-lists": [
      {
        "name": "interopt_scanner",
        "blockRequests": "never",
        "ipAddresses": [{ "ipAddress": "<scanner address>/32" }]
      }
    ]
  }
}

ModSecurity and Coraza

For ModSecurity or Coraza with the OWASP Core Rule Set, such as on a Kubernetes ingress controller, add an exclusion that removes the Core Rule Set for Interopt's addresses. It has to load before the Core Rule Set, for example in REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf. See the Core Rule Set's tuning guide.

SecRule REMOTE_ADDR "@ipMatch <scanner addresses, comma-separated>" \
    "id:1001,phase:1,pass,t:none,nolog,ctl:ruleRemoveByTag=OWASP_CRS"

Vercel Firewall

Vercel's own guides: custom rules and system bypass rules.

Bypass lets the request through custom rules and managed rulesets, bot protection included. Vercel's automatic DDoS mitigations are separate: on Pro and Enterprise, add a system bypass rule for the same addresses. Attack Mode challenges every visitor, and the scan can't pass a challenge. A deployment behind Deployment Protection asks every visitor to sign in to Vercel, so scan a domain it doesn't cover.

Other WAFs, CDNs and bot protection

For Sucuri, DataDome, Barracuda, FortiWeb, Azure API Management policies, an application's own rate limiter or any other control:

• Allow Interopt's addresses as the connecting address, limited to the hosts in scope, ahead of every rule that can block, challenge or rate-limit.
• Use the control's allow or bypass action, not its log-only mode for everyone.
• When one control sits behind another, such as a WAF behind a CDN, allow the addresses at the outer one first. The inner one sees the outer one's addresses unless it reads the client address from a header the outer one sets.
• Where a rate limit can't be exempted, choose Light under Load on your application so the scan sends requests more slowly. See Configure a scan.

Check that it worked

• In your WAF: filter its events or logs on Interopt's addresses once the scan is preparing. Requests to the start page with an interopt_probe parameter should show your allow rule matching, and none blocked or challenged.
• In Interopt: on the scan's Overview tab, the timeline moves past "Checking the running application" into Mapping. A scan paused with a reason that begins "A WAF in front of" is still blocked: the rule doesn't match yet, sits below a rule that blocks, or misses one of the controls.