This article will give you a quick overview of security headers, explain how they work, why they’re important, and show you the top security headers you need to know.
It’s easy to overlook security headers in website audits.
Website security may not seem like an SEO concern to some, but it becomes one once a site is hacked and search traffic dwindles to zero.
Whenever anything is published on the Internet, security headers should be a major concern.
You can easily set them up and they will keep your visitors safe while they browse your website.
Why Do Security Headers Exist?
The HTTP header response carries security header directives that must be followed by browsers.
HTTP headers are responses sent by a web server to a browser when it tries to access a web page.
In header responses, we communicate things like when the page doesn’t exist (400 response header).
The website’s domain is fine to download a font from Google, but any other data outside the domain should not be trusted.
In that example, the directive instructs the browser to trust Google fonts, but not files that originate from anywhere else but the website.
By blocking malicious files from other websites, a security directive like that prevents a browser from downloading malicious files.
They contain instructions and restrictions that prevent inadvertent security incidents.
Why Do We Need Security Headers?
Security tests are continually performed on websites by automated bot software.
Websites can be hardened against malicious attacks by putting security headers on their pages.
Keeping components up-to-date and using security plugins can prevent websites from using security headers, but this unnecessarily exposes the site and its visitors to security risks.
Security plugins cannot prevent ad injections that steal revenue from a website.
Most importantly, security headers ensure that a website keeps functioning normally because they are relatively easy to implement.
The top five security headers
1. The Content-Security-Policy (CSP)
CSPs help to prevent Cross-Site Scripting (XSS) attacks and data injection attacks on a website.
(XSS) Cross-Site Scripting
Cross-site scripting (XSS) exploit occurs when hackers exploit a security hole to upload malicious scripts to a website, which are then downloaded to the victim’s computer.
Due to inadequate sanitization of input files, XSS attacks take advantage of flaws in content management systems.
For instance: Generally, an email form should be coded to expect restricted input.
If a form is poorly coded, it may allow other input which can result in malicious files being injected.
Passwords can be stolen by using XSS attacks or as part of a multi-step hacking event.
Injection attacks are described as a serious security risk by the Open Web Application Security Project (OWASP):
“The act of injection is defined as providing data to an application in such a way that changes the meaning of commands sent to the interpreter.”
The most common SQL injection example is the attacker sending “101 OR 1=1” instead of just “101”. By including this data in a SQL query, it returns ALL records rather than just one.
A successful attack on these interpreters can lead to significant data breaches, or even the loss of control of a browser, application, or server if they have a lot of access to it. Injection attacks together constitute a large portion of the serious application security risks.”
The CSP header instructs a browser to only download resources from a specified set of domains.
Any attacker attempting to download malicious scripts from a server outside of the trusted group will be blocked.
The level of security in a content security policy can be governed by the publisher’s requirements.
Note: Setup of this system can be a bit tricky, however, because in order to whitelist any scripts or resources downloaded from outside your domain, you must list them all.
2. Strict-Transport-Security Header (HSTS)
Strict-Transport-Security Header (HSTS) is also known as HTTP Strict Transport Security.
301 redirects from HTTP to HTTPS are common on most websites.
It’s not enough to secure the website as it is still vulnerable to man-in-the-middle attacks.
In addition to preventing Downgrading and Taking Advantage of Insecure Redirects, HSTS prevents attackers from downgrading HTTPS connections to HTTP connections.
For instance: Whenever a person types example.com to access a site, without actually typing in the HTTPS part (or when they just type HTTP out of habit), the potential for a man-in-the-middle attack exists.
Attacks of this type can compromise the connection between the site visitor and the site, and any sensitive information exchanged between the visitor and the site can be seen by the attacker.
As an example, an attacker can intercept cookies containing sensitive information such as login credentials.
US government lists three scenarios in which HTTPS can be downgraded to HTTP, allowing an attacker to compromise security.
HTTPS can be downgraded in three ways:
As soon as the user types in “gsa.gov”, browsers default to using http://.
It may be possible for a user to click on an older link that incorrectly uses an http:// URL.
Users may have hostile networks that actively rewrite https:// links to http://.
With the HSTS header, the browser is forced to reject all HTTP connections automatically.
A secure HTTPS protocol is needed in order to access all of a website’s content when the HSTS header is present.
The security header is designed to prevent certain types of exploits, such as those caused by malicious user-generated content.
By “sniffing” the web page elements, a browser can download them and render them correctly, for instance when the browser does not have the metadata it needs to display the element.
In order to render an element, the browser sniffs it to determine what it is (an image, text, etc.).
This and other related attacks can be stopped by disabling the ability for browsers to “sniff” for the content type through the X-Content-Type-Options header.
X-Frame-Options prevents click-jacking attacks.
According to Mozilla, click-jacking is:
“It involves tricking a user into clicking on something that is not what they expect it to be.
For example, this can be used to steal login credentials or to install malware unwittingly with the user’s permission.”
With X-Frame-Options, a web page cannot be displayed in an iframe.
However, the feature prevents more than just iframe-based attacks.
Frame sniffing is defined by Microsoft as follows:
“Framesniffing” makes use of browser functionality to steal data from websites.
These attacks may affect web applications that allow their content to be hosted in IFRAMEs that cross domains.
X-Frame-Options allows you to control whether a page can be inserted into an IFRAME.
X-Frame-Options headers can protect web applications from Framesniffing since Framesniffing relies on being able to place the victim site in an IFRAME.”
Click-jacking attacks are explained in detail by the Open Web Application Security Project (OWASP):
“Imagine an attacker who creates a web site that offers a free iPod when someone clicks on it.
However, the attacker has loaded an iframe on top of that web page and positioned the “delete all messages” button right on top of the “free iPod” button.
Rather than clicking on the “free iPod” button, the victim accidentally hits the “delete all messages” button which isn’t visible.
By clicking on the link, the attacker hijacked the user’s click, thus the name, “Clickjacking”.
In addition to protecting your visitors, the X-Frame-Options header is also important for the reputation of your site.
A section of OWASP’s web page on click-jacking describes how hackers gained control of microphones and cameras through a click-jacking attack, thus cementing Flash’s adverse reputation as a security nightmare.
An online reputation as a security risk is bad for business, especially in social media.
Using the X-Frame-Options header is a good security measure.
5. The Referrer-Policy
Referrer-Policy headers are used to allow a website publisher to control what information visitors are sent when they click links to visit other websites.
Visitors’ browsers provide information about what web page referred them to another site when they click a link and land there.
Whenever you look at your server logs, you will see referrer information that indicates which sites brought visitors to your site.
The URL of the site that refers a visitor to another visitor may, however, contain sensitive information that may be leaked.
By limiting the amount of information sent after a visitor clicks a link, the Referrer-Policy works.
Alternatively, a website publisher can choose to send just the domain name or the entire URL string instead of providing information pertaining to the referrer.
Referrer-Policy can be used to send the following directives:
Referrer-Policy: no referral when downgrading.
Referrer policy: origin-if-cross-origin.
Referrer policy settings that include the Header “no-referrer-when-downgrade” are a common example. This means that referrer information is sent to websites that are HTTPS-compliant but no referrer information is sent to links on untrusted HTTP websites.
Affiliate links will not be affected by the referrer-policy setting.
This referrer information is incorporated into the landing page URL, so both the referrer information as well as the affiliate earnings are recorded by the merchant who received the affiliate referral.
Implementation of security headers
Setting security headers can be accomplished in a variety of ways, but one popular option is to use a .htaccess file.
A benefit of using the .htaccess file is that it reduces the need to download another plug-in.
Plugins that are poorly coded become security risks, so minimizing the number of plugins installed is a good idea.
Note: It is important to note that every implementation of a security header will differ according to the specifics of each website, especially the Content-Security-Policy (CSP).