sfw/fix
ERR_BLOCKED_BY_XSS_AUDITOR low

net::ERR_BLOCKED_BY_XSS_AUDITOR (legacy reflected-XSS block)

Old Chrome's XSS Auditor blocked a page because request input appeared reflected in the response, usually a false positive.

What you see

This page isn't working
Chrome detected unusual code on this page and blocked it to protect your personal information.
ERR_BLOCKED_BY_XSS_AUDITOR

What’s actually happening

A form submit or a link with query parameters lands on a blank Chrome error page instead of your content. It only ever happened in Chrome and Edge, never Firefox or Safari, and almost always on pages that echo submitted input back into the HTML, like a search results page printing the query. The Auditor saw a parameter value show up verbatim in the response body and assumed reflected XSS. If you're still seeing this code today, you're on a Chrome build older than 78 (released October 2019), because the feature was removed there.

Common causes

  • The page reflects a request parameter (GET or POST) into the response HTML unencoded enough that Chrome's heuristic matched it against the request, e.g. a search box echoing q= into the page
  • A legitimate form posting HTML or script-like text (a CMS editor, a code-snippet field, a comment box) that gets rendered back to the user
  • Chrome's heuristic firing on a benign overlap between input and output, a known false-positive class the Auditor was notorious for
  • A genuinely reflected XSS vector, in the minority of cases, where unsanitized input really is written into the page
  • An ancient Chromium-based browser or embedded WebView still shipping the Auditor (pre-78)

How to fix it

  1. Confirm the browser versionThe XSS Auditor was disabled in August 2019 and removed in Chrome 78. If a current Chrome shows this, it's actually an old build or a stale embedded WebView. Update the browser or the host app and the error disappears, because the code path no longer exists.
  2. Stop reflecting raw inputOn the page that triggers it, HTML-encode every user-supplied value before writing it into the response (htmlspecialchars in PHP, autoescaping templates, textContent over innerHTML in JS). Encoded output doesn't match the request string, so the heuristic never fires and you close a real XSS hole at the same time.
  3. Move to a Content-Security-PolicyCSP is the modern replacement. Ship a policy like default-src 'self'; script-src 'self' and drop inline scripts, or use nonces/hashes for the ones you keep. A blocking CSP stops reflected and stored XSS far more reliably than the Auditor ever did.
  4. Do not re-enable the old headerYou may find advice to send X-XSS-Protection: 1; mode=block. Don't. That header is ignored by modern browsers and the one behavior it changed (mode=block) was itself a source of cross-site info leaks. Set X-XSS-Protection: 0 if a scanner complains, and rely on CSP.

Stop it recurring

Encode all reflected input at output time and ship a strict Content-Security-Policy; both kill the false positive and the actual XSS risk.

Related errors