X-XSS-Protection: header should be disabled by default

Following a decision by Google Chrome developers to disable Auditor, developers should be able to disable the auditor for older browsers and set it to 0. The X-XSS-PROTECTION header was found to have a multitude of issues, instead of helping the developers protect their application. The following discussion describes the issue at hand with more references: https://github.com/OWASP/CheatSheetSeries/issues/376 A PR is currently open to tackle the issue at the CheatSheet Series project: https://github.com/OWASP/CheatSheetSeries/pull/378

If approved, we can help with creating a PR for this issue. Available for further discussions 😄

[EvanHahn]

Helmet v4 (and x-xss-protection@2) was just released, which disables this header.

Thanks for reporting and for discussing this with me.

[EvanHahn]

To anyone reading this issue who wants to disable the header: you don’t need this module. Here’s a very short piece of custom middleware that does the trick:

app.use(function (req, res, next) {
  res.setHeader('X-XSS-Protection', '0');
  next();
});

As I said before, I think users should be able to set the header’s value to whatever suits them. If that’s 0, great—if that’s 1; mode=block, that’s okay too.

But what should the default value be?

1. Setting the default to 1; mode=block protects everyone from trivial XSS but puts everyone at risk of side-channel attacks.
2. Setting the default to 0 protects 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 set by Helmet. And again: users should be able to change the default to whatever suits them.

The Secure Headers module is also dealing with this issue and I want to discuss with them a bit, but that’s my tentative plan.