3 Security Headers That Every Site Should Have

31 Jan 3 Security Headers That Every Site Should Have

Clickjacking, XSS and CSRF, exploits that have been around for 15+ years now and still form the basis for many vulnerabilities on the web today. If you spend any time around bug bounty programs you will notice similar patterns with these exploits, that many could have been prevented with just a few HTTP Headers in place. A website that goes into production without these is asking for an exploit. Even if they have “other mitigations” in place, on most platforms it takes all of 5 minutes to add in a custom header which could save your site from an unfortunate vulnerability.

These headers should be on any “go live” checklist unless there is a specific reason why they can’t be (For example it’s an internal site that is going to be framed elsewhere, you may not want to disallow frames). While this site focuses on .net core, these headers are language and web server agnostic and can be used on any site.

X-Frame-Options

X-Frame-Options tells the browser that if your site is placed inside a HTML frame, to not render anything. This is super important when trying to protect yourself against click jacking attempts.

In the early days of the web, Javascript frame breakers were all the rage to stop people from framing your site. Ever seen this sort of code?

It was almost a staple in the early 2000’s. But like most things Javascript, people found ways to get around it and invented a frame breaker breaker. Other issues included human error aka ensuring that the frame breaker code was actually on every page of your site. That one page you forgot to include the javascript snippet on? Yeah that’s the exact page someone used for clickjacking. Happens all the time!

A http header that disallows frames server wide with full browser support should be your go to even if you want to use a javascript framebreaker side by side.

X-Frame-Options is most commonly set to be “SameOrigin”, that is that the website can frame itself. But unless you actually have a need for this, the option of “Deny” is your best bet.

A guide to using X-Frame-Options in .net core can be found here.

X-XSS-Protection

X-XSS-Protection is a header that activates a browsers own XSS protection. All modern browsers have inbuilt XSS filtering capabilities that try and catch XSS vulnerabilities before the page is fully rendered to you. By default these are turned on in the browser, but a user may go ahead and switch them off. By using the X-XSS-Protection header, you can actually tell the browser to ignore what the user has done and enforce the inbuilt filter.

By using the “1;mode=block” setting, you can actually go further and stop the entire document from rendering if a XSS attack is found anywhere. (By default it removes only the portion of the document that it detects as XSS).

Infact, “1;mode=block” should be the only setting you use for X-XSS-Protection. Using only “1” could actually be a vulnerability in of itself. For more read here : http://blog.innerht.ml/the-misunderstood-x-xss-protection/

Another thing to note is that the browsers XSS filters are routinely bypassed by new ways of sneaking things through. It’s never going to be 100%. But it’s always a base level of protection that you would be silly to not utilize.

A guide to using X-XSS-Protection in .net core can be found here.

X-Content-Type-Options

X-Content-Type-Options is a header I often see missed because in of itself, it’s not an exploit per-say, but it’s usually paired up with another vulnerability to create something much more damaging. A good example is the Json Array Vulnerability (Now fixed) that was around for a very long time. It allowed browsers to run a JSON array as javascript, something that would not be allowed had X-Content-Type-Options been set.

The header stops a browser “guessing” or ignoring what the mime type of a file is and acting on it accordingly. For example if you reference a resource in a <script> tag, that resource has to have a mime-type of javascript. If instead it returns text/plain, your browser will not bother running it as a script. Without the header, your browser really doesn’t care and will attempt to run it anyway.

A guide to using X-Content-Type-Options in .net core can be found here.

Content Security Policy

While you are reviewing security, why not take a look at implementing a Content Security Policy (CSP). While it doesn’t have as large of browser support as the previous headers mentioned, it is the future of securing browsers and wouldn’t hurt to add. After all, when it comes to security you want to close all the doors, not just the ones you think people will actually walk through.

Written by Wade, source: http://dotnetcoretutorials.com/2017/01/21/3-security-headers-every-site/