github
Should x-xss-protection default to “0” instead of “1; mode=block”
Related https://github.com/helmetjs/x-xss-protection/issues/14
There’s some good discussion there. The owasp consensus is that it does more harm than good.
We’ve always allowed people to override this setting, but maybe we should change the default.
I'm the maintainer of the linked module and have been thinking about this for awhile. My thoughts:
I see two reasonable options for this header's default value: 0 and 1; mode=block. Which should be the default?
- Setting the default to
1; mode=blockprotects everyone from trivial XSS but puts everyone at risk of side-channel attacks. - Setting the default to
0protects everyone from side-channel attacks, but puts some people at risk for trivial XSS.
No matter what we choose, the default will put some people at risk.
I'm coming around to the idea that the default should be 0 but there should also be a strong default Content Security Policy. And in any case, users should be able to change the default to whatever suits them.
What do you think?
As a meta point, I think the maintainers of Helmet, Secure Headers, and many other modules need to answer questions like this. Should we find a way to work together? I don't think we need to do anything fancy, but it could be good to get all of us on an email list or something. I think this isn't the place to discuss that, but want to float the idea.
I'll reply in here, instead of the issue at Helmet's repository. Adding on what you mentioned, it's pretty clear what the compromise is. Coming from a security PoV, the risk that can mitigated is the one that will be accepted. Side-channel attacks are much harder to prevent, while XSS attacks can be blocked by another header for example, the CSP, and in other various ways (encoding, sanitization, etc.), not to mention the weak protection that is being provided.
If I were to recommend, I'd follow point number 2 and disable the XSS auditor.
As for CSP, setting a default might be tricky. I mean I like it, but not so advanced developers won't like it. It could be an opportunity to make CSP implemented and more wide-spread if libraries set secure defaults. How I am looking at it:
- If a developer doesn't want it, they can remove it. In all cases, they won't implement CSP, so why even bother? Let them remove it and live their happy vulnerable lives. I am certain lots of panic will occur for developers that barely understand the technology, and recommendations to remove it will be everywhere on StackOverflow, such as SSL validity checks. What I am trying to say is people will always run to the easy road just to fix an blocker. Doesn't mean it's the correct thing, so I wouldn't worry much if a note was set in the documentation about it.
- If a developer doesn't know about it, but wants to make their website work with it, they'll start implementing it step by step. (it gave awareness and motivation)
- If a developer is invested in security, they'll be happy to see that a library already sets secure defaults.
cc @lweichselbaum for additional input on CSP, and what they think about implementing a CSP secure default.
@ThunderSon thanks for the followup in another thread! This library will set csp by default that should work for apps out of the box and is a nice mix of common needs for apps without sacrificing all the security. I'm not sure how many people actually use it, but I'm a strong advocate of providing a default and I've seen it work wonders. Of course, I have no idea how many people actually use the default or benefit from it but I'm not worried about negative effects here.
Content-Security-Policy: default-src 'self' https:; font-src 'self' https: data:; img-src 'self' https: data:; object-src 'none'; script-src https:; style-src 'self' https: 'unsafe-inline'
That script-src https: is definitely problematic with script gadgets. I could definitely soften my stance there.
@oreoshake how are you thinking of softening it up? What is an example that you're thinking of?
@oreoshake how are you thinking of softening it up?
My stance on the default policy as-is (or at all) being a good idea. @EvanHahn does helmet set a default policy?
The current version does not, but I intend to add one in the next major version of Helmet.
I think I'm going to try and tackle this in the next release. It's a breaking change and https://github.com/github/secure_headers/pull/422 really needs to get out (and is also a breaking change).
Only confirm https://github.com/OWASP/CheatSheetSeries/issues/376#issuecomment-602663932:
I've been studying this issue for a while and it's dangerous to set this header. It makes sites that are not vulnerable to XSS, vulnerable. ... Developers need to either remove the header or set it to zero, I think the debate is over. There is NO good reason to set this header to blocking mode.
Note: Init link https://github.com/helmetjs/x-xss-protection/issues/14 now https://github.com/helmetjs/helmet/issues/230
@ho4ho at this point, I don't think there's any disagreement, there just hasn't been a pull request for it.
Does anyone know if there's a similar issue in rails/rails? Might as well change it there too.
Circling back to this, GitHub has defaulted to 0. It's past time to do the same here.
It should be noted that many modern browsers don't support this header:
- Chrome has an "Intent to Deprecate and Remove the XSS Auditor".
- Firefox have not (to my surprise), and will not implement
X-XSS-Protection.- Edge retired their XSS filter
The MDN docs also warn against the use of this header:
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.
