How widely used are security-based HTTP response headers?

https://scotthelme.co.uk/how-widely-used-are-security-based-http-response-headers/

by bikeshack • 11 years ago

116 34 11 years ago

scotthelme.co.uk

martinrue• 11 years ago

For 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

gkop• 11 years ago

This is the counterpart for Ruby: https://github.com/twitter/secureheaders

thephyber• 11 years ago

Lusca[1] is the NPM module for use with Express that comes in the KrakenJS middleware (open sourced by PayPal).

    app.use(lusca.csrf());
    app.use(lusca.csp({ /* ... */}));
    app.use(lusca.xframe('SAMEORIGIN'));
    app.use(lusca.p3p('ABCDEF'));
    app.use(lusca.hsts({ maxAge: 31536000 }));
    app.use(lusca.xssProtection(true));

[1] https://github.com/krakenjs/lusca

nly3• 11 years ago

I'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.

JoshTriplett5• 11 years ago

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.

jacobparker• 11 years ago

There's no way to whitelist inline code

That's not completely true - the nonce attribute (specify a nonce in the CSP header, have nonce=that on every script tag) or by sending the hashes of the inline scripts upfront in the CSP header.

It doesn't give you inline code in attributes (e.g. onclick) but it's a big help for migrating.

lol768• 11 years ago

You might find the Content-Security-Policy-Report-Only header useful for identifying CSP issues and deploying policies without actually blocking anything.

STRML• 11 years ago

It'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.

eli• 11 years ago

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.

JoshTriplett5• 11 years ago

I've found the X-Frame-Options (to prevent clickjacking via iframe)

I wish some way existed to prevent clickjacking (e.g. via invisible iframe) without actually banning frames. There are useful applications for framing another site that can't be achieved by any other means, apart from writing a browser extension. And framing a site without making it invisible seems like unfortunate collateral damage.

hannob• 11 years ago

Dan Kaminsky is working on something: http://dankaminsky.com/2015/08/09/defcon-23-lets-end-clickja...

Scott_Helme_7• 11 years ago

It's worth pointing out that you can replace the functionality of the X-Frame-Options header with Content-Security-Policy using the frame-ancestors directive if you want to: https://scotthelme.co.uk/csp-cheat-sheet/#frame-ancestors

A world with opt-in to unsafe behaviour would be great, but a long way off I fear. Thanks for mentioning the header check service!

A0102• 11 years ago

I 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?

nly3• 11 years ago

Because it doesn't eliminate the Server header, "off" will return "Server: nginx". Just one of several "fuck you" features in nginx.

A0102• 11 years ago

Server: header makes people gone mad?

Scott_Helme_7• 11 years ago

Sadly nly is right. The only other option to change this is the ngx_headers_more module, but that still requires a rebuild. I suppose that way you at least get a little more functionality for your troubles.

jacquesm• 11 years ago

HN 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 <nojs> </nojs> 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.

dantillberg2• 11 years ago

How about a <nojs> </nojs> pair in the primary document disabling any kind of javascript execution in the space between the tags.

But wouldn't folks still be able to inject scripts by just writing `</nojs><script>alert('hi')</script><nojs>`?

JoshTriplett5• 11 years ago

CSP does exactly that; you can just ban inline scripts entirely.

dantillberg2• 11 years ago

This post encouraged me to go through my own website and add a moderately strict CSP header, sans 'unsafe-inline' scripts/styles. Thanks!

Scott_Helme_7• 11 years ago

If you like, you could also add reporting to your CSP and get live feedback on it with https://report-uri.io

It's free to sign up and use.

idlewords• 11 years ago

CSP breaks bookmarklets in Firefox, which makes it rather user-hostile. This is properly Mozilla's fault, but they've shown no interest in fixing it.

https://bugzilla.mozilla.org/show_bug.cgi?id=866522

Scott_Helme_7• 11 years ago

Interesting, I don't use Firefox enough to have noticed this. Would it be possible to whitelist this functionality in your CSP in the short term without adversely affecting the strength of your policy?

hyperpape• 11 years ago

Idlewords runs Pinboard, a bookmarking site, so I'm guessing he's worried about the impact of other people turning on CSP. I don't use Pinboard, but I believe I've encountered the problem using the Instapaper bookmarklet.

jasonlfunk• 11 years ago

Can you help me understand the graphs? What is being plotted on the X axis?

cbr• 11 years ago

I think popularity, from most to least?

Scott_Helme_7• 11 years ago

Yes, sorry that wasn't clear. I scanned the sites in groups of 4,000. The x axis is each group in descending order from the top of the Alexa list to the bottom.

greggman• 11 years ago

I'd really like to know if any of you have used the report feature. It seems like any report you got would show you a bug in your code. What were the bugs? How many reports did you get?

Scott_Helme_7• 11 years ago

To be honest, most of the reports I get for my sites aren't legitimate issues. Malware on the endpoint makes changes to pages (like inserting ads) that generate reports, certain browser features trigger changes that cause reports. There are also browser plugins and addons that make changes which also cause reports to be sent. You can always create a report only CSP which will send reports but not block actions on the page and use my service at https://report-uri.io to gather the reports for you to look at them. All free and no risk of breaking anything, if you're interested.

How widely used are security-based HTTP response headers?

Related Stories