-
-
Notifications
You must be signed in to change notification settings - Fork 16.7k
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
Security improvement: don't reveal powered-by #2813
Conversation
The first thing recommended when setting up an Express instance is to secure it by removing its "X-Powered-By" header. https://www.npmjs.com/package/helmet https://blog.risingstack.com/node-js-security-checklist/ https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/ So let's save cycles by not setting this header in the first place. This header is also totally useless. If some people are needing it somewhere for a very specific usecase they can add a little custom middleware that returns the "X-Powered-By" header again.
As this is a breaking change, this is targeted for 5.x. |
Hi! Can you elaborate on what exactly the security risk is that we would be resolving with this change? As long as things like IIS, ASP.Net, PHP, and more are sending this header by default, I don't see any good reason for Express to stop doing it unless you can provide very concrete information (and not speculation) on how this header is a security risk. |
After talking around, as long as PHP, ASP.Net and others are sending |
When a web server/application is to be secured, be it PHP, Apache, Nginx, (whatever the software) the first thing to do is removing the web server/framework/etc. fingerprints if possible, i.e. the The previously cited links all agree on it:
Here is literature from SANS, one of the most trusted source for computer security training (ask your network): Here is literature from OWASP, which provides recommendations widely followed by the industry (ask your network):
The "X-Powered-By" header is not listed as a useful HTTP header: Now why would Helmet gather more than 1500 stars? Who the hell are those freaks who are not doing as PHP and as ASP.Net? Node.js and Express are about aesthetic, stripping the useless, removing the cruft and going fast! All what you are ceaselessly doing in all your contributions. So now let's reverse the burden of proof: where are the proofs that using |
I would like to hear why Microsoft still ships it on by default with ASP.Net and why PHP ships it on by default, etc. If you can provide that information, perhaps you can sway us, but for now, we won't be changing this feature. Helmet does WAY MORE than turn off this header. If you showed me a module that literally did nothing but disable this header and had 1500 stars, that's a different story. Basically, get ASP.Net and PHP to commit to removing it and we will as well. Until then, you can either turn it off like you have to do with every platform or create a module and publish it to npm that has it off by default for people to use. |
Of course Helmet does way more than just removing the @EvanHahn, @evilpacket, @gergelyke @hacksparrow, @crandmck, as authors of the aforementioned software and articles, would you care to convince @dougwilson to remove the |
+1 for removal - I think @madarche summarized all the reasons pretty well |
Look, removing the header provides no security benefits. Removing the "frivolous" header only does that--removes a non-useful header. What is the point of the header you say? Well, it's to give credit to the hard-working people who have enabled you to write your code so fast, who you never even gave money to, as this is free, open source. This library is even MIT licensed, so please, feel free to fork it and provide your own copy that does not include the header if you wish. A lot of people incorrectly assume that "if that header is not there, attackers won't know I'm running Express!". I was walked-though a commercial security product that does server identification by security engineering. This software includes specific detection for Express.js, even (being popular), and these are some of the rules it uses:
Even then, when using the server vulnerability attacking part of that software, it will simply try Express.js attacks against a server, regardless of if it even thinks the server is Express.js. This is because, since everything is configurable, there is no good way to truly know. The X-Powered-By and Server headers are frivolous headers, I agree. Does removing them help with security? No, only increases obscurity, which is not a valid form of security by any means. Just think of it this way: we give you Express.js for free and in return "trick" you into giving us credit for our hard work or you have to put 1 line of code in your application, which is already code and your developers should understand how to code when using Express.js. There is no further discussion to be had on this topic. |
The first thing recommended when setting up an Express instance is to secure it by removing its "X-Powered-By" header.
https://www.npmjs.com/package/helmet
https://blog.risingstack.com/node-js-security-checklist/
https://strongloop.com/strongblog/best-practices-for-express-in-production-part-one-security/
So let's save cycles by not setting this header in the first place.
This header is also totally useless. If some people are needing it somewhere for a very specific usecase they can add a little custom middleware that returns the "X-Powered-By" header again.