Building secure Web apps isn’t exactly easy, but there are a number of small tweaks you can implement using HTTP security headers to help protect yourself against attacks.
With relatively simple configuration changes, modern headers like CONTENT-SECURITY-POLICY and X-FRAME-OPTIONS allow you to protect your site against cross-site-scripting attacks or click jacking with a small change.
Unfortunately, most people don’t know about security headers or how easy they are to implement. A new Web app, securityheaders.io, gives you actionable fixes for your Web app by simply typing in a domain name.
Because HTTP is an extensible protocol browsers have pioneered some useful headers to prevent or increase the difficulty of exploiting these vulnerabilities. Knowing what they are and when to apply them can help you increase the security of your system.
1. Content-Security-Policy- How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing, have the browser straight up refuse it?
That’s the promise of Content-Security-Policy.
Adding the Content-Security-Policy header with the appropriate value allows you to restrict the origin of the following:
script-src: JavaScript code (biggest reason to use this header)
connect-src: XMLHttpRequest, WebSockets, and EventSource.
font-src: fonts
frame-src: frame ulrs
img-src: images
media-src: audio & video
object-src: Flash (and other plugins)
style-src: CSS
And if you want to test the waters, you can use use the ‘Content-Security-Policy-Report-Only’ header to do a dry run of your policy and have the browser post the results to a URL of your choosing.
X-Frame-Options- Stop Clickjacking with one simple header:
X-Frame-Options: DENY
This will cause browsers to refuse requests for framing in that page.
Supplying the value ‘SAMEORIGIN’ will allow framing only from the same origin and ‘ALLOW FROM http://url-here.example.com’ will allow you to specify an origin.
2. X-Content-Type-Options-Letting your users upload files is inherently dangerous, serving up files uploaded by users is even more dangerous and difficult to get right.
This isn’t made any easier by browsers second-guessing the Content-Type of what you’re serving by doing Mime Sniffing.
3. The X-Content-Type-Options allows you to, in effect, say to browsers that yes, you know what you’re doing, the Content-Type is correct with it’s only allowed value: ‘nosniff’.
4. Strict-Transport-Security- My online banking system uses HTTPS, providing authenticity (that yes, I really am connecting to my bank) and transport security (anybody snooping in would only see the encrypted traffic).
However, there is a problem with it…
When I type “onlinebanking.example.com” into the address bar of my browser, it will connect to plain old HTTP by default. It’s only if the server then redirects the user to HTTPS (which is a bad idea in theory, but a good one in practice) that I get my secure connection. Unfortunately this redirecting gives an attacker a window to play man-in-the-middle. To solve this the Strict-Transport-Security header was added.
The HTTP Strict-Transport-Security (HSTS) header instructs the browser to (for a given time) only use https. If for instance, you go to https://hsts.example.com and (among others) it returns the following header:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Then even typing in http://hsts.example.com will make the browser connect to https://hsts.example.com.
Conclusion--Using the HTTP headers discussed above allows you to quickly and easily protect your users from XSS, Clickjacking, Mime sniffing vulnerabilities and Man-In-The-Middle attacks.
If you aren’t using these headers yet, now might be a good time to introduce them to your application or webserver configuration.