Chrome ERR_BLOCKED_BY_XSS_AUDITOR: Fix Blocked POST Requests

What Triggers This Error

You're working on a web app — maybe a payment form, a third-party API integration, or a login flow from a different domain. Chrome shows ERR_BLOCKED_BY_XSS_AUDITOR in the console and your POST never reaches the server. Don't panic. You're not under attack. Chrome's built-in XSS auditor is guessing wrong — it sees a normal cross-origin request and flags it as malicious.

Here's the real-world scenario: you're building a WordPress site that sends user data to a CRM on api.crm.com/submit. That's a cross-origin POST. Chrome's auditor, especially in older versions (Chrome 65 and earlier), kills it dead. In Chrome 75+, they finally turned off the auditor by default, but some corporate-managed browsers and older versions still have it on. The fix depends on what you control.

The 30-Second Fix: Disable the Auditor in Chrome Flags

This works if you're testing locally and just need Chrome to shut up. It's not a permanent solution for production users, but it'll confirm the auditor is the problem.

1. Open Chrome and type chrome://flags in the address bar. Hit Enter.
2. In the search box, type XSS. You'll see a flag called XSS Auditor or something like Enable XSS Auditor.
3. Click the dropdown next to it and select Disabled.
4. Chrome will ask you to relaunch. Click Relaunch Now.

After Chrome restarts, reload your page and try the POST again. If the error disappears, you've confirmed the cause. But don't stop here — you need a real fix for your users.

The 5-Minute Fix: Add a Server Response Header

This is the proper fix. You tell Chrome "I know what I'm doing, don't block this." You add the X-XSS-Protection header to the response from the server you're POSTing to. That's the target server, not your own.

Set it to 0 — that disables the auditor for the whole page. Here's how to do it in common setups:

Apache (in .htaccess or vhost config)

Header always set X-XSS-Protection "0"

Nginx (in server block or location)

add_header X-XSS-Protection "0";

IIS (in web.config)

<system.webServer>
  <httpProtocol>
    <customHeaders>
      <add name="X-XSS-Protection" value="0" />
    </customHeaders>
  </httpProtocol>
</system.webServer>

PHP (if you control the target server's code)

header('X-XSS-Protection: 0');

After you add the header, clear your cache and test the POST again. You should see the request go through. If you can't modify the target server, move to the advanced fix.

The Advanced Fix (15+ Minutes): Disable the Auditor via Chrome Command Line

This is for your own testing or for a managed corporate environment. Don't push this to end users — that's bad practice. But if you're a developer and need to test, or you're the IT admin managing Chrome for your team, this works.

1. Close all Chrome windows completely.
2. Right-click your Chrome shortcut (on Taskbar or Desktop) and select Properties.
3. In the Target field, add this at the end of the existing path, after a space:

--disable-xss-auditor

It should look like: "C:\Program Files\Google\Chrome\Application\chrome.exe" --disable-xss-auditor

Click Apply then OK. Launch Chrome from that shortcut and test. The error should be gone.

For macOS, open Terminal and run:

open /Applications/Google\ Chrome.app --args --disable-xss-auditor

For Linux, launch Chrome from the command line:

google-chrome --disable-xss-auditor

Which Fix Should You Pick?

Simple. If you control the target server, use the header fix. That's the real solution. If you're a dev testing locally, use the flag fix. If you're the IT admin managing a fleet of Chrome browsers, go with the command-line flag — but only for a while. The XSS auditor is deprecated and removed in Chrome 78+, so eventually everyone will update and the error dies on its own.

One last thing: never disable the auditor on untrusted sites. Your bank, your email — leave security on. This fix is for your own apps where you know the traffic is clean.