With the recent Chrome 57 build, the XSS auditor detection (and blocking capabilities) has been improved to the point that many web-based services suddendly stopped working giving this rather obscure HTTP error: The issue is almost always caused by some HTML-formatted content being sent via POST within the request, which is a rather common behavior for a number of modern web tools and features – such as WYSIWYG editors, interactive uploaders, AJAX-based CMS real-time updates, and so on. When the tool is developed by third-parties, the best thing you can do is to open an issue with the developers and make them go through the hassle: however, there are scenarios where you *need* to anticipate the fix by yourself, not to mention the cases when *you* are the tool developer. This is what happened to me yesterday, when I had to apply a quick fix to a tool I coded for a friend of mine a while ago: an interactive electronic invoice display which follows the recent italian electronic invoice PA standards. What I did there was use an AJAX-based function to pass the whole content of an entire HTML page and then displaying it using the same HTTP request, which was the only working way I found to support the drag-and-drop feature in a cross-browser way: more specifically, I couldn’t use the great HTML5 native drag-drop feature because it’s not working well in IE < 10, which I really had to support. The script worked really well until a couple days ago, when it suddenly started to raise the above error. After digging here and there, I finally stumbled upon this post which (kinda) explained the fact. According to the post author, the most straightforward way to overcome the issue was adding the following key/value pair to the response headers: This can be done in a number of ways, depending on the server-side technology you’re using. ASP.NET Add the following within the Web.Configfile: Or just add a within your MVC controller/ASPX page code. PHP Use the Header function to add something like the following before the first ouput: … And so on. Unfortunately, such approach didn’t fix my problem at all. Then I thought about getting rid of the raw HTML code by encoding it in some convenient way, such as the always-good Base64 schema… And I had much better luck with that. What I did was downloading this neat jQuery-base64 plugin (many thanks to the author, Tao Klerks), adding it to my HTML page using a standard <script> element within the <head> block and then encoding the input right before POSTing it in the following way: Then I switched to the server-side PHP code and base64-decoded the received input from the result page – using the PHP-native base64_decode function – in the following way: … And that was enough to get rid of the ERR_BLOCKED_BY_XSS_AUDITOR error. That’s it for now: happy coding!