New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 29 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug

Show other hotlists

Hotlists containing this issue:

Sign in to add a comment

False positives with ERR_BLOCKED_BY_XSS_AUDITOR

Reported by, Mar 17 2017 Back to list

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.98 Safari/537.36

Steps to reproduce the problem:
1. Submit a post request with a Twitter embed
2. See the error

What is the expected behavior?
To not think a twitter embed is an XSS attack, like usual.

What went wrong?
It broke

Did this work before? Yes 55

Chrome version: 57.0.2987.98  Channel: n/a
OS Version: Antergos Arch
Flash Version:
Components: Blink>SecurityFeature
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Thanks for the report!

Can you please help improve this report by including URLs on which you are able to reproduce this problem, and logs from the Console tab from the Chrome developer tools?
Labels: Needs-Feedback
This is happening to my VBulletin forums site at
This has begun happening when submitting posts, or editing posts. 

It began a few days ago after the latest installation of Chrome.
39.2 KB View Download
I will add details to the above:

As an admin, the issue occurs 100% of the time if I click "edit" and then "save" on any article on the home page at  If required, I can provide credentials to duplicate.  

There is a related bug report:

Comment 6 Deleted

Comment 7 Deleted

Our cloud-based EDI service has a few thousand ad-agency customers and we've just started having a rush of complaints for a very similar issue. We have the agencies upload their EDI text files to our translation server and we encourage them to use the Chrome Browser. In the last couple of weeks they are all starting to get the "Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards)." message. The file transfer goes through, but the users don't realize the transfer is happening anyway and call in thinking they've been blocked by Chrome. Because the command line workaround to suppress this feature is too complicated for our non-computer-savvy user base, we're being forced to have them use another browser. We'd love to stop doing this and continue directing them to use Chrome, but this bug makes that impossible.

349 KB View Download
We are getting this also when trying to modify reports in our Oracle based CRM system. It is cloud based also and I have no idea what OS they are running. I am surprised this bug is classified "unconfirmed." I am running the beta version of 58 and therefore do not have the problem. My users do not have that luxury as they are running on VDIs that are all using V57 and updates are synchronized. I do not know when you plan to release V58, but hopefully soon.
The bug is "Unconfirmed" insofar as the reproduction cases listed so far are all entirely different (and the root causes are likely different) and no workable reproduction steps have been provided to Google thus far.

A site can opt-out of XSS Auditor scanning by sending an "X-XSS-Protection: 0" response header.
We can reproduce the problem 100% of the time.
 ljfabiano3@: Are you able to provide step-by-step instructions (URLs, credentials) that would allow us to see what you're seeing?

Comment 13 Deleted

I am also able to reproduce this error 100% of the time by going into edit mode for an article and clicking 'save'. This is in vBulletin 4.

I began receiving many emails from users asking if out site was 'hacked' or if we were trying to install malware on their computers. To the non-computer savvy user, that error message could look pretty frightening. 

This began suddenly with the latest version of Chrome. Our online magazine is quite large, with over 80,000 registered users and many more non-registered readers. We've had to put up messages recommending the use of Firefox or... bite my tongue... Internet Explorer. to mitigate the issue. 

Last night I added the 'protection "0"' header to the site which seems to have remedied the issue for now, but I'm also seeing this problem on other sites I visit. Right now I installed Firefox and am using that.  I hope Chrome gets fixed, since that's my preferred browser, and the browser we have always officially recommended to our readers.
Here's your 100% reproduction case in simple form:

Just hit the button.

Full code of the example:
Project Member

Comment 16 by, Apr 5 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "" to the cc list and removing "Needs-Feedback" label.

For more details visit - Your friendly Sheriffbot
Components: -Blink>SecurityFeature Blink>SecurityFeature>XSSAuditor
The reproduction case in comment 15 is POSTing a `<script>` tag that's reflected in the landing page. That's more or less exactly what the XSS auditor is looking for. It sounds like the case in comment 8 is similar.

If this flow is essential to your application, and you're confident that you're escaping user generate data correctly, then configuring your server to send `X-XSS-Protection: 0` along with the response from the POST endpoint is the best solution.

Are there cases where Chrome is giving a similar error message in the absence of a POSTed `<script>` or `<style>` element?
Labels: OS-Android OS-Chrome OS-Mac OS-Windows
You shouldn't need to completely turn off a feature just because Chrome picks up "script", that's far too broad and breaks far too many things.
 Issue 709139  has been merged into this issue.
 Issue 710862  has been merged into this issue.
Status: Assigned
I have the same problem which seems to be due to having a you tube link on my web page.
If I try to update the page with Chrome then I get this XSS.Auditor message.

youtube is a Google product!!

Here is the page url
Is there a better way other than trial and error to determine why exactly XSS Auditor is blocking the page?  Wouldn't it be orders-of-magnitude better for web developers to modify the offending html/javascript code than the disable XSS Auditor via server headers?  The recommendation to disable XSS auditor seems to be in direct contradiction to the reason XSS Auditor was changed to block by default as discussed in "motivation" section here:!msg/blink-dev/aZsNygF84JM/86EbD_q0CAAJ .  I would expect some kind of information to show up in the javascript console or in the Security tab of Chrome's Dev Tools, and it's even discussed in the forum above that there ARE console errors and therefore we have "effectively already gone through a 'deprecation period' where we've [been] given notice of the problem".  I am not seeing any kind of message in either the console or the security tab.

I was hoping that the issue would be cleared in Chrome ver. 58 but I just got 58 today and it's still there.  Unfortunately, I can't make the page where I'm seeing the issue public, and since I don't know what's causing the issue it would be hard to recreate a test page that I could make public.

As for the particular page where I'm seeing the issue, the page doesn't use iframes and the POST is not sending <script> or <style> tags in the POST'ed form data. It looks like the data is successfully POST'ed to the server, but the result page is blocked.

Would XSS auditor block the page if the page is POST'ing an <a> tag that has an onclick set?  For example, if this(parsed request body data) were part of the POST'ed form data: 

H_FIELD_LINK:<a href="xxx0000$.field_link?fn_item_id=00000" target="popup" onclick="'xxx0000$.field_link?fn_item_id=00000','popup_35','scrollbars=1,width=1000,height=800'); return false;">LV_ERROR</a>

Is it an issue anytime there is a <script> tag inside the <form> element?  I was looking in the POST request body data instead of just the html source and didn't see any <script> tags.  I suppose I don't understand what was meant by "POSTing a `<script>` tag".
Update - the problem was the <a> tag which had an onclick set and was being POST'ed as form data.  This was being done with the use of a hidden input; the the <a> tag's html was escaped and put inside the value of the hidden input.  After removing the onclick and instead setting an event handler in javascript elsewhere the problem was fixed.  No disabling of XSS Auditor needed! 

I would still really like to some kind of console message to help point developers in the right direction... 
Confirm this bug. It is triggered on submitting post on
Also experiencing this bug in Chrome 58 when trying to administer a legacy zope2 site


Comment 29 Deleted


We have a customer who's experiencing this issue on a Windows 10 PC that has Chrome Browser v60 installed. Preview has never worked on this machine before But it is working fine from another Windows 7 PC that has Chrome Browser v58 without any problem.

Any update on this bug?

Thank you!
I confirm the workaround for triggering this bug by
sending a "X-XSS-Protection: 0" response header fixes this here.
 Issue 717707  has been merged into this issue.
Issue 780116 has been merged into this issue.
Labels: Hotlist-EnamelAndFriendsFixIt

Comment 35 Deleted

Comment 36 Deleted

Comment 37 Deleted

 Issue 812255  has been merged into this issue.
 Issue 79014  has been merged into this issue.
I have had this issue reported to me by a user and was able to recreate the issue. Developer Tools screenshot attached. 


Please fix this issue. I will have other users running into this problem and it will cause significant disruption to users.
EASI system Bug in Chrom 2.15.18.PNG
25.8 KB View Download
rknox, the link you provided requires some sort of login ... what I'll need from you is a view-source of the page where the issue is happening along with the complete url (plus post body, if a post).

The reference URL in C40 doesn't seem reasonable as some sort of punctuation [<>'"] is required to engage the auditor in the first place.

Comment 42 Deleted

Comment 43 Deleted

Comment 44 Deleted

Comment 45 Deleted

Comment 46 Deleted

Comments on this issue will be closed if they do not contribute to resolving any issue.

In all cases thus far, this feature is working as expected. If you believe you've found a false positive issue in the XSS Auditor, please provide the information requested in Comment #41 above.

> Is there a better way other than trial and error to determine 
> why exactly XSS Auditor is blocking the page? 

If you choose "View Page Source" on the page that triggers the XSS Auditor, Chrome will highlight the offending reflection in red, as shown in the attached screenshot.

If you'd like to learn more about this feature, see
175 KB View Download

Comment 48 Deleted

Comment 49 Deleted

Labels: -Hotlist-EnamelAndFriendsFixIt
I get this error when embedding YouTube videos in a web form. The text posted is e.g. "<iframe width="560" height="315" src="" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe>"
If I don't embed this code, the error does not occur. The error has the following text: "This page isn’t working
Chrome detected unusual code on this page and blocked it to protect your personal information (for example, passwords, phone numbers, and credit cards).
Try visiting the site's homepage.
After getting the error message and reloading the browser, the form is actually updated with the embedded video, so the only problem is an extra button click, but if my collaborators don't think to reload the browser, they can't post the content,
My Chrome version is "Version 65.0.3325.146 (Official Build) (64-bit)".
When I view the page source I don't see any red highlighting, but I suspect the problem is in this snippet: "<tr>
<td valign='top'>Video&nbsp;<a href='#sternchen' title='Fields with a star (*) are only visible for club members after registration'>*</a></td>
<td valign='top'><iframe width="560" height="315" src="" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen></iframe></td>
I can recreate the error every time.

Sign in to add a comment