Allowing the scanner

1. Fixed IP addresses

Every scan leaves from these addresses. They belong to our hosting provider's region and may be shared with its other customers, so do not allow them on their own: combine them with the request header in section 3, which only our scans of your site carry.

The account owner copies the current addresses from the Scanner identity card on their Account page, together with the header value. Until addresses are listed there, use the header alone.

2. User-Agent

The scanner presents itself as a current desktop Chrome and carries no scanner token in its User-Agent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) … Chrome/151.0.0.0 Safari/537.36

The Chrome version follows the browser engine the scanner runs, so it moves with each engine update. A "bot" token in the User-Agent makes some servers answer with a different page or a refusal before the audit starts, so it is not how the scanner is recognised. Rules written before 15 September 2026 that match AccessProBot/1.0 should drop that clause and keep the header and the addresses.

3. Per-site request header

The X-AccessPro-Scan-Token header carries a value that belongs to one account and one site. It is sent with every request to that site and to no other host, and it opens nothing anywhere else. The account owner finds it under Scanner identity on their Account page by entering the site, together with a ready-made rule.

Cloudflare

Security → WAF → Custom rules → Create rule. Paste the expression from the account's Scanner identity card: it matches your host, the header value, the User-Agent token and the fixed addresses together. Action: Skip, with Bot Fight Mode, Super Bot Fight Mode and managed challenges ticked. Put the rule above any blocking rule.

Other firewalls and WAFs

Allow requests whose X-AccessPro-Scan-Token header equals the account's value, ideally only from the fixed addresses. An address-only rule also admits other tenants of the same hosting region; use one only for a login that is already protected by credentials.

Pages behind a login

On the Developer plan and up, a scan can sign in first and test the pages a signed-in customer sees. Developer includes 5 login scans a month; Team and Business have no monthly cap.

• Check the login page first. Under Scan behind a login on the dashboard, Check login page loads it from the scanner's own address and tells you whether the site refused the scanner, which sign-in fields it can see, and which sign-in method to pick. Nothing is typed or submitted, and no scan is used.
• One-time codes. If the site emails or texts a verification code, the scan waits and the report page asks for it. Type the code, or paste the sign-in link from the email. The scan holds the session for 3 minutes, and the code is never stored.

Sites behind Cloudflare Access or single sign-on

For a site that requires a login, the scanner can sign in with a username and password, with a code or link sent by email, or with request headers the site accepts as identity. For Cloudflare Access, create a service token and a policy with the action Service Auth on the application; the account owner then chooses Request headers when starting the scan and enters the token's Client ID and Client Secret. The values are used for that scan only and are never stored.

What the scanner does not do

• It does not hide its origin behind residential or rotating proxies.
• It does not solve or bypass CAPTCHAs or bot challenges.
• It does not send a site's credentials or headers to any other host.
• It does not keep the full content of signed-in pages. For each finding it keeps the rule, the element's selector, a short HTML fragment of that element, its accessible name and the page title.

How accurate those findings are is measured in public on the scanner accuracy benchmark. For anything this page does not answer, see how to contact us