Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

XSS Filter #273

Closed
effen1337 opened this issue Oct 13, 2020 · 4 comments
Closed

XSS Filter #273

effen1337 opened this issue Oct 13, 2020 · 4 comments

Comments

@effen1337
Copy link

I'm aware that there was a discussion about the xss filter header but I still couldn't see why enabling it would be "bad" in a sense, wouldn't it just provide extra protection while we are handling user input ourselves?

@EvanHahn
Copy link
Member

Good question. This is something I thought a lot about.

When enabled, the X-XSS-Protection header theoretically protects users from trivial reflected XSS attacks. (Note that it can't protect you from all kinds of XSS—just reflected XSS.) Though limited, this is good!

However, it comes with a cost: you're more vulnerable to side-channel attacks. For example, I can put your page in an iframe. If I can trigger the browser's XSS filter, the page will behave differently, and I can learn things about your page. Might be fine, but might be dangerous.

Most browsers (such as Chrome) have either deprecated this header or never supported it, and basically everyone recommends using Content-Security-Policy instead. You're much safer with a strong CSP than with the X-XSS-Protection header enabled.

If you're sure you want to enable it, you can set up your own middleware and disable Helmet's:

// Not recommended, but you can do this:
app.use(helmet({
  xssFilter: false,
}));

app.use(function (req, res, next) {
  res.setHeader('X-XSS-Protection', '1; mode=block');
  next();
});

You can read more in #230.

I'm going to close this issue because I think I've answered your question, but let me know if that's wrong and I can reopen!

@effen1337
Copy link
Author

Thank you a lot for the detailed awesome answer.

Most browsers (such as Chrome) have either deprecated this header or never supported it, and basically everyone > recommends using Content-Security-Policy instead. You're much safer with a strong CSP than with the X-XSS-Protection header enabled.

But what if we had both a strict CSP and the XSS protection header enabled? Wouldn't that be the best thing to do?

@EvanHahn
Copy link
Member

Enabling the XSS filter could still open you up to side-channel attacks in browsers that support X-XSS-Protection in two cases:

  1. The browser doesn't support Content Security Policy, or doesn't support some CSP directive you set.
  2. Your CSP would allow reflected XSS somehow, likely with 'unsafe-inline'.

Does that answer your question?

@effen1337
Copy link
Author

Ahhh, I see what you mean. Yes it does. Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants