-
Notifications
You must be signed in to change notification settings - Fork 367
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
Comments
Good question. This is something I thought a lot about. When enabled, the 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 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! |
Thank you a lot for the detailed awesome answer.
But what if we had both a strict CSP and the XSS protection header enabled? Wouldn't that be the best thing to do? |
Enabling the XSS filter could still open you up to side-channel attacks in browsers that support
Does that answer your question? |
Ahhh, I see what you mean. Yes it does. Thank you! |
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?
The text was updated successfully, but these errors were encountered: