Open ghost opened 4 years ago
The document quoted says:
Although these protections are largely unnecessary in modern browsers [...] they can still provide protections for users of older web browsers
What improvement to web security does your proposal provide, that would offset the reduction in web security for older browsers that would come from changing/removing the XXP header recommendation?
The point is to clarify the documentation. You inform people that
they can still provide protections for users of older web browsers that don’t yet support CSP
but you also write
Mandatory for all new websites. Recommended for existing websites.
Maybe it should be more detailed? About "if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead"
And a little bit about browser compatibility: some legacy browsers like Chrome old versions (<79) can support XSS Auditor and it can be maybe more dangerous 1;mode=block
for Chrome than 0
for old IE http://homakov.blogspot.com/2013/02/hacking-with-xss-auditor.html. I am not sure there is a perfect option so I am asking you is it really mandatory to set 1;mode=block
or not?
I was slightly confused as well at first when I read it as well, with regards to the existing/new sites point. I’m not familiar enough with the intricacies of XXP to respond to the other points, but your explanation will help the folks who do understand what might be done to improve things here. Thanks for taking the time to clarify.
On Fri, Apr 24, 2020 at 18:11 xyzxyxzxzxyz notifications@github.com wrote:
The point is to clarify the documentation. You inform people that "they can still provide protections for users of older web browsers that don’t yet support CSP" but you also write "mandatory for all new websites, recommended for existing websites". Maybe it should be more detailed?
About " if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead"
And a little bit about browser compatibility: some legacy browsers like Chrome old versions (<79) can support XSS Auditor and it can be maybe more dangerous 1;mode=block for Chrome than 0 for old IE http://homakov.blogspot.com/2013/02/hacking-with-xss-auditor.html. I am not sure there is a perfect option so I am asking you is it really mandatory to set 1;mode=block or not? Maybe documentation should be more detailed?
— You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/mozilla/infosec.mozilla.org/issues/124#issuecomment-619296581, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAWUDAF6AM3RJI6Q3HYE2DROI2C5ANCNFSM4MQPM53A .
The wording in the guidance is quite confusing for this header:
New websites should use this header, but given the small risk of false positives, it is only recommended for existing sites.
I'm not really sure what this is trying to say. Is this meant to be advising people to implement it or not? Or is it trying to say that new websites SHOULD use it, and existing sites COULD use it (to use RFC language)?
I had the same interrogation than rbsec
The wording in the guidance is quite confusing for this header:
New websites should use this header, but given the small risk of false positives, it is only recommended for existing sites.
I'm not really sure what this is trying to say. Is this meant to be advising people to implement it or not? Or is it trying to say that new websites SHOULD use it, and existing sites COULD use it (to use RFC language)?
The answer is here: https://infosec.mozilla.org/guidelines/web_security
Mandatory for new websites Recommended for existing websites
This header has also been deprecated in Chrome, Edge, (and Chromium based browsers) for good reasons. It created more problems than actual benefits. It basically only provided a false sense of security. There's always been ways to bypass it. It also caused some vulnerabilities in some situations, such as XS-Leaks and ironically XSS.
Mozilla's own documentation recommends against it. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection
This feature is non-standard and is not on a standards track. Do not use it on production sites facing the Web: it will not work for every user. There may also be large incompatibilities between implementations and the behavior may change in the future.
Warning: Even though this feature can protect users of older web browsers that don't yet support CSP, in some cases, XSS protection can create XSS vulnerabilities in otherwise safe websites. See the section below for more information.
I see no point in even recommending this header anymore, whether old or new applications.
https://blog.innerht.ml/the-misunderstood-x-xss-protection/ https://thexssrat.medium.com/x-xss-protection-headers-protection-or-vulnerability-bc7213951320
I found it confusing reading this guide and it recommending using XXP in order to support old browsers while MDN indicates that it should not be used on production sites facing the web. The two recommendations seem at odds.
Removed in #183
Please update: https://infosec.mozilla.org/guidelines/web_security
The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks. Although these protections are largely unnecessary in modern browsers when sites implement a strong Content-Security-Policy that disables the use of inline JavaScript ('unsafe-inline'), they can still provide protections for users of older web browsers that don't yet support CSP.
Firefox have not, and will not implement X-XSS-Protection
This means that if you do not need to support legacy browsers, it is recommended that you use Content-Security-Policy without allowing unsafe-inline scripts instead.
(from https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-XSS-Protection)