Chrome, along with Edge, Opera and Safari, has built in support for detecting and preventing Cross Site Scripting (XSS) attacks. This works well as a safety net to protect users when websites fail to protect themselves from such attacks, but can cause issues with applications which allow users to post HTML in forms. This shows in chrome as an error page with the text "ERR_BLOCKED_BY_XSS_AUDITOR" and can be quite intimidating for users trying to perform a legitimate operation.

What triggers the XSS auditor?

The XSS auditor gets triggered when Chrome detects that HTML code that's been submitted to a page will be shown back to the user. Common use cases that require such an interaction with a web page would be those of a Content Management System allowing a user to edit a page, comment systems which allow the use of HTML, discussion forums and so on.

Importantly, for the error to be triggered in Chrome, the submitted HTML must be rendered back to the user on the same page load that it was submitted. This means that if you follow best practice and redirect away from a page which performs an operation such as saving a comment (without returning any content) then you'll be fine (provided you've sanitised your data properly, of course!).

What can be done to avoid such errors?

As mentioned above, the simplest solution for developers is to perform a temporary redirect (HTTP 302) after any action which accepts user input and saves it. The redirect can even be to the same page. This has many more benefits than avoiding the XSS auditor such as preventing users performing an action twice by pressing the refresh button.

Another potential solution is to disable the XSS auditor on pages which you accept the submission of HTML code. As this has obvious drawbacks I won't provide a code sample, but the Mozilla documentation is a good place to start if the preferred solution isn't possible.