Browser Integrity Check off

What it is

Browser Integrity Check is disabled.

Why it matters

It filters requests with headers characteristic of scrapers and abusive bots, at essentially no cost to real browsers. With it off, the cheapest layer of bot filtering is not running.

What Browser Integrity Check actually does

Browser Integrity Check inspects incoming request headers for the signatures of abusive automation — spam bots, scrapers and clients lying about who they are — and challenges or blocks the request before it reaches your origin. It lives at Security → Settings → Browser Integrity Check and is on by default for new zones, which is why finding it off usually means someone turned it off during an integration and never turned it back.

The error a blocked visitor sees

When the check blocks a request, the visitor gets Cloudflare error 1010 — worth recognising so you can tell a real false positive from background bot noise:

Why it gets turned off — and the better answer

The usual story: a webhook sender, monitoring agent or API client with a bare-bones HTTP library trips the check, and the zone-wide toggle is the first thing that makes the errors stop. That trades one noisy integration for protection on every route. The better answer is to keep the check on and exempt the specific path:

Fix it manually

Re-enable the zone-wide toggle at Security → Settings, add a configuration rule scoped to any path that legitimately serves non-browser clients, and watch the security events log (Security → Events) for a day — real false positives show up there with the exact rule that fired.

How lumioguard fixes it

The scan reads the zone setting and flags it alongside the routes your repo actually serves, so you can see which paths would need an exemption before flipping the toggle. The fix arrives as a guide with the setting, the scoped rule, and the events query to confirm nothing legitimate is caught.