Did you ever heard the statement "a fish rots from the head down"? This phrase is often used to blame the leadership for the failure of an organization, but it can be also used to depict an flawed web site or web application: paraphrasing that same concept, we could say that potentially unsecure web platforms can be seen from their HTTP response headers.
As a matter of fact, although there are a lot of things that can be done to secure a web site, HTTP Security Headers will always be a good place to start - for a number of reasons:
- They are really easy to implement (and understand) and require slight (if not tiny) configuration changes.
- They have a tremendous cost-benefit gain ratio: we'll be able to greatly increase our web site security layer in less than 5 minutes.
- They will effectively mitigate attacks and prevent your website from being hijacked.
- They are absolutely required nowadays to pass Penetration Tests, Vulnerability Scans, Risk Assessments, Data Security checklists and any other decent IT audit.
In this post we'll do our best to explain how they work and why we need them: in this other post we'll see how we can implement these good practices in a Windows Server with IIS using the web.config file; we'll see how to implement them in Apache in another follow-up article and, last but not least, we'll show how to deal with them from a Linux environment powered by Nginx.
Introducing HTTP Security Headers
Each time a browser navigates to a web site it actually issues a HTTP Request to the web server hosting that site: the server responds with some HTML content, which is delivered together with a set of metadata and other useful info that will be used by the client to handle a number of tasks, such as: content caching, language & localization, character encoding, and so on. These info are called HTTP Response Headers; some of them are also called Security Headers because they control the client browser's behaviour regarding the received HTML content. For example, they can force the browser to communicate over HTTPS only, force the browser to block any FRAME, IFRAME or other SRC content coming by third-party servers, and so on.
Here are the most important of them:
- X-Frame-Options: protects from ClickJacking by preventing FRAMES and IFRAMES to load on your site from specific sources (for example, different web servers).
- HTTP Strict Transport Security (HSTS): tells the web browser to access the web server over HTTPS only, thus ensuring that each and every connection will only be estabilished through secure channels.
- X-XSS-Protection: protects from XSS (aka Cross-Site Scripting) by enabling a specific filter built into most modern browsers: although it's enabled by default with decent settings, it's better to explicitly enable (and configure) it to strengthen our web site even more.
- X-Content-Type-Options: prevents the browser from downloading, viewing and/or executing a response that differs from the expected and declared content-type, thus reducing the risk of executing malicious software or download harmful files.
- Content Security Policy: prevents attacks such as XSS (aka Cross-Site Scripting) and other code-injection based attacks by defining which content the browser should load and which not.
- Public-Key-Pins: tells the web browser to use a public key to connect to the web server in order to prevent Man-In-The-Middle type attacks delivered using rogue, fake, forged or compromised X.509 certificates by adding another security layer.
- Referrer Policy, also known as the new kid on the block, as its specifications has been a W3C Candidate Recommendation as of January 26, 2017! Anyway, this header is used to determine if the URL of the webpage that linked to the resource being requested has to be sent along with the request or not; the default value (if nothing is specified) is to strip it when going from a page using HTTPS to a page using unsecure HTTP, and do nothing for the remaining cases.
For additional info regarding HTTP Security Headers and their importance in web development nowadays it's highly advisable to check out the OWASP Secure Headers Project, born with the precise intention of raising general awareness around the knowledge and the widespread usage of these headers.
Now that we know the basics, let's see how we can implement them:
- Implement HTTP Security Headers in IIS 7+ using the web.config file.
- Implement HTTP Security Headers in Apache using the httpd.conf file.
- Implement HTTP Security Headers in Ngnix using the nginx.conf file.
3 Comments on “What are HTTP Security Headers and how to properly implement them in IIS, Apache and Nginx to secure your web site”