It's not just my site but other sites with a valid report value set to a secure scheme. This shows up on YouTube and by extension any site that frames YouTube also gets this error in their console. 

Deleted: youtube.png 77.2 KB

	youtube.png 77.2 KB View Download

Screenshot of the YouTube site.

Deleted: youtube-site.png 117 KB

	youtube-site.png 117 KB View Download

I guess there's also a security aspect to this. "The default protections will be applied" probably means that mode=block is being disabled? 

After further testing this only happens when the report address isn't on the same origin. The following header does not cause the error on my site.

x-xss-protection:1; mode=block; report=https://scotthelme.co.uk/d/xss/enforce

Deleted: same-origin.png 86.5 KB

	same-origin.png 86.5 KB View Download

This is a bug here: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp?l=433&rcl=c7c0bb037fb28f7203d61d6ca7b943ffaad7916e

Basically, we are trying to block the report because it's not same origin, but in the process of doing so we clear the report URI. We then overwrite the error with a complaint that the report URI is mixed content (because "" is not a secure URI).

Putting an "else" between the blocks is probably the fix.

Regressing CL: https://chromium-review.googlesource.com/c/chromium/src/+/768367

After further digging it seems that Chrome intended to stop reports being sent to another origin. 

This diff here highlights the introduction of the change, which is also the cause of this bug: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp?l=433&rcl=0da6dcdbe8e34740133773d20cc466b89d399d0a&dlp=chromium&dlf=src/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp&dlc=0976634972849914b28d12d134ceed05d99f89df&dlr=213&dlgp=third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp&dlgr=chromium/chromium/src&drp=chromium&drf=src/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp&drc=0da6dcdbe8e34740133773d20cc466b89d399d0a&drr=214&drgp=third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp&drgr=chromium/chromium/src

The issue referenced is behind a security flag (I'm guessing) so I can't see that: https://bugs.chromium.org/p/chromium/issues/detail?id=441275

The Chrome Stable Channel Update does however contain information on the bug that was resolved: https://chromereleases.googleblog.com/2018/01/stable-channel-update-for-desktop_24.html

[$N/a][441275] Low CVE-2018-6051: Referrer leak in XSS Auditor. Reported by Antonio Sanso (@asanso) on 2014-12-11

The bug was reported over 3 years ago and (bearing in mind I can't read the bug) seems to imply that the referrer is leaked when sending an XSS Auditor report to another origin. If that's the case then this shouldn't really be considered a leak, the site has chosen to configure the reporting endpoint. This is how the current reporting for CSP, HPKP and Expect-CT all work too, the site chooses where the browser should dispatch the reports to. CSP reports themselves also contain referrer data. 

Not only will this break reporting on my site and several others that I know of, YouTube are reporting cross-origin as shown above so this will break at least 1 Google property too.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/cc2d336ed7196d3351484a4e06a83208d5ec5ca6

commit cc2d336ed7196d3351484a4e06a83208d5ec5ca6
Author: Eric Lawrence <elawrence@chromium.org>
Date: Wed Jan 31 20:17:18 2018

Improve error message when XSSAuditor Report URL is invalid

The X-XSS-Protection report URL must be same-origin to the page that
triggered the report. An incorrect fall-through led to a misleading
error message in the Developer Tools console when this condition is not
met. This CL removes checking for a Mixed Content report URL because
it has been obsoleted by the same-origin requirement.

Bug:  807304 
Change-Id: I0505a6cd8c218302ffb8095550f5eb3143817951
Reviewed-on: https://chromium-review.googlesource.com/893605
Reviewed-by: Mike West <mkwst@chromium.org>
Commit-Queue: Eric Lawrence <elawrence@chromium.org>
Cr-Commit-Position: refs/heads/master@{#533378}
[add] https://crrev.com/cc2d336ed7196d3351484a4e06a83208d5ec5ca6/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https-expected.txt
[add] https://crrev.com/cc2d336ed7196d3351484a4e06a83208d5ec5ca6/third_party/WebKit/LayoutTests/http/tests/security/xssAuditor/report-script-tag-cross-origin-https.html
[modify] https://crrev.com/cc2d336ed7196d3351484a4e06a83208d5ec5ca6/third_party/WebKit/Source/core/html/parser/XSSAuditor.cpp

 Issue 807795  has been merged into this issue.

 Issue 807581  has been merged into this issue.

 Issue 805787  has been merged into this issue.

The incorrect error message has been fixed as of 66.0.3336.0. The error message should now reflect the same-origin violation enforced by the CL in  Issue 441275 .

Are we sticking with the change or can we enable cross-origin reporting again now? 

RE #14: Either way, we're not tracking it in this issue. :) 

 Issue 441275  has been re-assigned to a developer for re-investigation, but I think MkWst is probably the person to convince vis-a-vis loosening the restriction again. (At which point we'll need to go put the mixed content check I just deleted back in).

Do I need to follow this up in 441275 or open a new issue to track this request?

Re #16: My recommendation would be to wait a few more days for any progress on 441275, and failing that, file a new issue with your case for relaxing the restriction.

 Issue 808525  has been merged into this issue.

(Just noting that "OS" here is set to "Windows", but this affects all OSes.)

I see the status of this issue is fixed but we are experiencing the same issue in chrome and firefox on osx, all browsers and the os are all update to date.

Deleted: Screen Shot 2018-02-28 at 12.46.40 PM.png 57.1 KB

	Screen Shot 2018-02-28 at 12.46.40 PM.png 57.1 KB View Download

RE #21: Firefox likely doesn't have this feature at all. The fix for this landed in Chrome 66.0.3336.0, which is still in Canary. You're almost certainly running an older version and need to wait for this fix to make it to Stable.

RE #22 I am having the latest version of Canary Chrome with version : 67.0.3362.0 (Official Build) canary . I still see the issue in my console. 

Looks like a chrome update will install the fix. version 65.0.3325.146 official build (64 bit) osx 10.11

Firefox appears to be OK.

Also not seeing it in safari.

Opera is showing the error - version 51.0.2830.40 
Browser identification
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.168 Safari/537.36 OPR/51.0.2830.40

Not sure if this is helping or tells you anything.

I have this build  65.0.3325.146  and still see the same error in the console, youtube not showing at all.

Same on my Browser Version 65.0.3325.146:

Error parsing header X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube: insecure reporting URL for secure page at character position 22. The default protections will be applied.

This issue is not resolved.

- Visit https://www.youtube.com/embed/C0DPdy98e4c

- Check the console, you will see the error below
Error parsing header X-XSS-Protection: 1; mode=block; report=https://www.google.com/appserve/security-bugs/log/youtube: insecure reporting URL for secure page at character position 22. The default protections will be applied.

I was able to embed the video on my web page (localhost) but I am unable to use the YouTube iFrame API (//www.youtube.com/iframe_api) with it.

The onready, onstatechange e.t.c events are not firing.

https://www.youtube.com/iframe_api also has the same error in the console.

It was working before. I believe the problem started after Chrome or some security update on YouTube server.

I Have Google Chrome Version 65.0.3325.162 and im facing the same error

To reiterate:

   The fix for this landed in Chrome 66.0.3336.0. 

The error message is harmless, and unrelated to any other issue; it does not interfere with video playback or any other behavior.

It does not interfere with the normal video playback but for some reasons YouTube iFrame API no longer work as expected.

The YouTube iFrame API is normally used for assessing the YouTube iframe even though my website is on a different domain but it no longer work as expected.

The onready and onstatechange events callback of the API is not firing.

RE #31: Unfortunately, this is not the place to diagnose issues in the YouTube API; you'll need to discuss this at https://developers.google.com/youtube/forum/discussion

I don't seem to be able to access  issue 441275 . Is there an already an issue to discuss the blocking of cross-origin XSS reporting?

 Issue 441275  was what led to the blockage of cross-origin XSS reports.
 Issue 811440  re-enabled cross-origin XSS reports for Chrome 66 and later.

Ah, thanks. Glad to hear it's enabled in v66. I'm also not able to view 811440:

You do not have permission to view the requested page.
Reason: User is not allowed to view this issue

Is https://bugs.chromium.org/p/chromium/issues/detail?id=811440 the right URL?

Re #35: I've made that issue visible.

What does the following issue means "Error parsing header X-XSS-Protection: : 1;mode=block: expected token to be 0 or 1 at character position 0. The default protections will be applied."

Deleted: error.png 91.2 KB

	error.png 91.2 KB View Download

@pthawa..., what Response Headers (for X-XSS-Protection) you see in Network panel?

The error message in #38 indicates that the X-XSS-Protection header value is malformed and contains errant characters before the "1" value. It needs to be fixed to avoid this message (although Chrome defaults to mode=block today)

Hi chromium@monorail-prod.appspotmail.com,

Please find the response header below.

   1. Cache-Control:
   no-store, no-cache, must-revalidate, post-check=0, pre-check=0
   2. Connection:
   close
   3. Content-Encoding:
   gzip
   4. Content-Length:
   8831
   5. Content-Type:
   text/html; charset=UTF-8
   6. Date:
   Wed, 06 Jun 2018 06:26:57 GMT
   7. Expires:
   Thu, 19 Nov 1981 08:52:00 GMT
   8. Pragma:
   no-cache
   9. Server:
   QMProprietary
   10. Strict-Transport-Security:
   max-age=16000000; includeSubDomains; preload;
   11. Vary:
   Accept-Encoding
   12. X-XSS-Protection:
   : 1;mode=block
   13.



Thanks
Piyush Thawakar  <https://www.linkedin.com/company/qualys>
Sr Engineer UI
pthawakar@qualys.com
T - +91 7038680837

Qualys, Inc. – Continuous Security
Blog <https://qualys.com/blog> | Community <https://community.qualys.com/>
 | Twitter <https://twitter.com/qualys>
<https://www.qualys.com/email-banner>

The line 

  X-XSS-Protection:: 1;mode=block

Needs to be

  X-XSS-Protection: 1;mode=block

Ya got that, Thanks for the help Guys...

Thanks
Piyush Thawakar  <https://www.linkedin.com/company/qualys>
Sr Engineer UI
pthawakar@qualys.com
T - +91 7038680837

Qualys, Inc. – Continuous Security
Blog <https://qualys.com/blog> | Community <https://community.qualys.com/>
 | Twitter <https://twitter.com/qualys>
<https://www.qualys.com/email-banner>

This happens in Chrome 67 as well. What's the solution?

Error parsing header X-XSS-Protection: 1; mode=block, 1: expected semicolon at character position 13. The default protections will be applied.


Thanks,
Bharathi K.

bharathik - based on the error message, it looks like the server is sending 
  X-XSS-Protection: 1; mode=block, 1
instead of
  X-XSS-Protection: 1; mode=block
the trailing ", 1" likely being the source of the error.

sorry for the Late reply, yes the trailing 1 is extra in your case, it
should be removed. In my issue reported the X-XSS header was taking an
extra ":" before 1, so I just removed the ":" from the header.
I wrote it like this -->  X-XSS-Protection 1; mode=block
Thanks
Piyush Thawakar  <https://www.linkedin.com/company/qualys>
Sr Engineer UI
pthawakar@qualys.com
T - +91 7038680837

Qualys, Inc. – Continuous Security
Blog <https://qualys.com/blog> | Community <https://community.qualys.com/>
 | Twitter <https://twitter.com/qualys>
<https://www.qualys.com/email-banner>