Cloudflare: Error 1010: Browser signature banned
Last verified
Error 1010: The owner of this website has banned your access based on your browser's signatureWhat it means
Error 1010 means the request was blocked based on characteristics of the client software rather than the person. Cloudflare's documentation lists two causes: a website owner blocked your request based on your client's web browser, and requests to *.pages.dev, *.workers.dev or a custom domain of a Pages project, where Browser Integrity Check treats a non-browser User-Agent as suspicious.
Browser Integrity Check looks for header patterns commonly used by abusive clients, including missing or non-standard User-Agent strings. Scripts using a library's default User-Agent frequently trigger it.
For the site owner, Cloudflare notes that Browser Integrity Check can be turned off in Security settings for regular zones, but it cannot be turned off on pages.dev or workers.dev hostnames, by the owner or by Cloudflare support.
What it looks like
# Cloudflare's documented fix for your own Pages/Workers API clients:
curl -H "User-Agent: acme-inventory-sync/2.1 (+https://acme.example/contact)" \
https://my-project.pages.dev/api/itemsWhy it happens
- The site has Browser Integrity Check enabled and the request looks like a non-browser or abusive client.
- The request goes to a pages.dev or workers.dev hostname with a library default User-Agent.
- Browser extensions or privacy tools stripped or altered standard headers.
- The owner created a rule targeting specific clients.
How to fix it
- Visitors: notify the site owner; if you cannot find a contact, Cloudflare suggests looking up the domain in WHOIS.
- For your own API clients calling a Pages or Workers hostname, Cloudflare's documented fix is to send a descriptive User-Agent that identifies your application.
- For someone else's site, do not impersonate a browser to get past the check; ask the owner for API access.
- Disable extensions that rewrite headers and retry in a standard browser.
- Site owners: review Browser Integrity Check and any user-agent rules; add skip rules for known integrations.
How to stop it recurring
Always identify your client with an honest, descriptive User-Agent including a contact URL. If you operate an API on Workers or Pages, document the header your clients must send, or serve the API from a custom domain where you control security settings.
Official documentation: developers.cloudflare.com/support/troubleshooting/http-status-codes/cloudflare-1xxx-errors/error-1010. See all Cloudflare error messages.
Related errors
Definitions
- CAPTCHACAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a challenge-response m
- Cloudflare Bot ManagementCloudflare Bot Management is the set of Cloudflare features (Bot Fight Mode, Super Bot Fight Mode and the Ente
- Cloudflare TurnstileCloudflare Turnstile is Cloudflare's free CAPTCHA replacement: a widget that runs invisible browser checks, is
- User AgentA user agent is a string that browsers send with every HTTP request identifying the browser type, version, and
- Rate LimitingRate limiting is a technique that controls the number of requests a client can make to a server within a given
Quick answers
What does "Error 1010: Browser signature banned" mean in Cloudflare?
Error 1010 means the request was blocked based on characteristics of the client software rather than the person. Cloudflare's documentation lists two causes: a website owner blocked your request based on your client's web browser, and requests to *.pages.dev , *.workers.dev or a custom domain of a Pages project, where Browser Integrity Check treats a non-browser User-Agent as suspicious.
How do I fix "Error 1010: Browser signature banned"?
1. Visitors: notify the site owner; if you cannot find a contact, Cloudflare suggests looking up the domain in WHOIS. 2. For your own API clients calling a Pages or Workers hostname, Cloudflare's documented fix is to send a descriptive User-Agent that identifies your application. 3. For someone else's site, do not impersonate a browser to get past the check; ask the owner for API access. 4. Disable extensions that rewrite headers and retry in a standard browser. 5. Site owners: review Browser Integrity Check and any user-agent rules; add skip rules for known integrations.
Retries and timeouts without writing the loop
Autonoly's HTTP Request node and browser steps have per-node retries, timeouts and continue-on-fail, so a transient 429 or 503 can back off instead of failing the run. It has no proxies or IP rotation: if a site blocks automated traffic, that block applies to Autonoly too.
Also see Error handling in workflows.