How widely used are security-based HTTP response headers?
scotthelme.co.uk
How widely used are security-based HTTP response headers?
1–10 of 36 posts
Re: How widely used are security-based HTTP response headers?
#2For people using Node/Express, Helmet is a useful little library that lets you add these security headers and CSP pretty easily: https://github.com/helmetjs/helmet
Re: How widely used are security-based HTTP response headers?
#3I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
Re: How widely used are security-based HTTP response headers?
#4It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites.
For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Security-Policy (to restrict eval, inline JS, JS and embed sources and more) to be the most useful headers by far. If you can run CSP without 'unsafe-eval' or 'unsafe-inline' and restrict all sources to your local domain, your site's security will be much better for it as an entire range of attacks is eliminated on modern browsers.
Of course they are all worth looking at. Scott's header test (https://securityheaders.io) is a great check for your own sites.
Re: How widely used are security-based HTTP response headers?
#5It's unfortunate that response headers on a secure website need to be bloated so much to receive benefits that should be default on modern sites. I imagine a world where you specifically have to opt-in to unsafe behavior, not the other way around, but of course this would break many existing sites. For those of you looking at this, I've found the X-Frame-Options (to prevent clickjacking via iframe) and Content-Securi…
Some day that will probably happen, but of course the issue is that it would break every site that relies on the less secure behavior.
Re: How widely used are security-based HTTP response headers?
#6I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?
Re: How widely used are security-based HTTP response headers?
#7I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
Re: How widely used are security-based HTTP response headers?
#8I gone through his previous blog post and found the changing Server: header field. Why have to waste time for rebuilding nginx from source for that? Why not just insert 'server_tokens off' in your nginx.conf?
Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.
Server: header makes people gone mad?
Re: How widely used are security-based HTTP response headers?
#9I've found HPKP and HSTS easy to trivial, but gave up on deploying CSP. It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
> It's major refactoring when so much stuff directly includes 3rd party CSS and script, or just injects static CSS and JS in to pages inline.
You can still use CSP, and whitelist specific third-party domains. (There's no way to whitelist inline code, though, and if there were it'd be more work than eliminating it and moving it to files.)
But the refactoring is well worth doing. By eliminating inline JavaScript and off-domain JavaScript, you eliminate the possibility of script injection. And directly including third-party JavaScript (or CSS, which can include JavaScript) opens you up to various kinds of attacks.
Re: How widely used are security-based HTTP response headers?
#10HN uses x-frame-options:"DENY" to good effect which takes care of a fair number of click-jack tricks, it also uses strict-transport-security.
But there is only so much you can do with headers, the real risks are in the documents themselves.
How about a pair in the primary document disabling any kind of javascript execution in the space between the tags. And those tags should only work in the primary document.