Security headers are easily overlooked in website audits.
While some may say that website security is not an SEO-related concern, it does become SEO-related when a site becomes hacked and search traffic dwindles to zero.
Security headers should be a top concern of everyone who publishes anything on the Internet.
The good news is that they are relatively simple to configure and will help keep your website and its visitors safe.
in this column, you’ll learn what security headers are and how they work as well as the top 5 security headers, how to implement them, which WordPress plugins you can use for setting security headers, and more.
Let’s get started!
What Are Security Headers?
Security headers are directives browsers must follow that are passed along through the HTTP header response.
An HTTP header is a response by a web server to a browser that is trying to access a web page.
The header response communicates things such as when the web page does not exist (400 response header).
Or that it’s okay to download a font from Google but not to trust any other data outside of the website’s domain.
In that example, the part that tells the browser that it’s okay to download Google fonts but not trust any files originating elsewhere other than the website itself is a security directive.
A security directive like that will block a browser from downloading malicious files from another website.
Security headers introduce restrictions and instructions that prevent unintended security events.
Why Use Security Headers?
Automated bot software are constantly probing and testing websites for security weaknesses.
Websites that use security headers are said to be hardened against security threats.
While a website can get along without using security headers by keeping its components up to date and using security plugins, doing so needlessly exposes the website and the site visitors to security risks.
For example, security plugins can’t stop ad injections that rob a site owner of ad revenue.
Perhaps the best reason to use security headers is because they are relatively easy to implement and ensure that a website keeps running normally.
Top 5 Security Headers
1. Content-Security-Policy (CSP)
A content security policy (CSP) helps to protect a website and the site visitors from Cross Site Scripting (XSS) attacks and from data injection attacks.
Cross-Site Scripting (XSS)
Cross-Site Scripting (XSS) exploits happen when hackers take advantage of a security hole to upload malicious scripts to a website which are then downloaded to a victim’s browser.
XSS attacks take advantage of flaws in a content management system that allows unexpected inputs to be injected because of insufficient user input file sanitization.
For example, ordinarily, an email form should be coded to expect a restricted input.
A poorly coded form may allow some other input which can then lead to an injection of malicious files.
An XSS attack can be used to steal passwords or as part of a multi-step hacking event.
The Open Web Application Security Project (OWASP) describes injection attacks as a serious security risk:
“Injection is an attacker’s attempt to send data to an application in a way that will change the meaning of commands being sent to an interpreter.
For example, the most common example is SQL injection, where an attacker sends “101 OR 1=1” instead of just “101”. When included in a SQL query, this data changes the meaning to return ALL records instead of just one.
…Frequently these interpreters run with a lot of access, so a successful attack can easily result in significant data breaches, or even loss of control of a browser, application, or server. Taken together, injection attacks are a huge percentage of the serious application security risk.”
The content security policy by itself does not 100% protect a site from attacks but it does help to diminish the possibility of a cross site scripting attack.
A CSP header instructs the browser to only download resources from a set group of domains and only from those domains.
Any attacker that is downloading malicious scripts from another server outside of that trusted group will be blocked.
Creating a content security policy can be as strict or as lenient as a publisher requires.
Warning: However, setting one up can be a little tricky because you have to list all of the scripts and resources that are being downloaded from outside of your domain in order to whitelist them.
2. Strict-Transport-Security Header (HSTS)
The Strict-Transport-Security Header is also called the HTTP Strict Transport Security header (HSTS).
Many websites only have a 301 redirect from HTTP to HTTPS.
But that’s not enough to keep the website secure because the website is still vulnerable to a man-in-the-middle attack.
HSTS prevents an attacker from downgrading the HTTPS connection to an HTTP connection which then allows the attacker to take advantage of insecure redirects.
For example, if a person types in example.com to access a site, without actually typing in the https part (or they simply type http out of habit), then the opportunity exists for a man-in-the-middle attack.
That kind of attack can compromise the site visitors’ connection to the website and any sensitive information exchanged between the visitor and the website becomes visible to the attacker.
For example, an attacker can intercept cookies that contain sensitive information like login credentials.
The United States government lists three scenarios where HTTPS can be downgraded to HTTP and subsequently allow an attacker to compromise security.
These are the three ways HTTPS can be downgraded:
- When a user types “gsa.gov” into the URL bar, browsers default to using http://.
- A user may click on an old link that mistakenly uses an http:// URL.
- A user’s network may be hostile and actively rewrite https:// links to http://.
The HSTS header prevents this from happening by forcing the browser to absolutely not accept an HTTP connection.
The HTTP Strict Transport Security (HSTS) header tells the browser that the entire website should only be accessed by a secure HTTPS protocol.
Side Note: How To Preload HSTS Into Chrome
On a related note, Google Chrome has an HSTS Preload program where publishers can submit their sites to be listed by Chrome as only accessible via the HTTPS protocol.
Many Chrome-based web browsers will subsequently preload these websites with HTTPS and only via HTTPS, hard coding that standard right into the browser.
Qualifying sites must already be serving the HSTS security header.
These are the four requirements needed to qualify for Chrome HSTS preloading:
- “Serve a valid certificate.
- Redirect from HTTP to HTTPS on the same host, if you are listening on port 80.
- Serve all subdomains over HTTPS. In particular, you must support HTTPS for the www subdomain if a DNS record for that subdomain exists.
- Serve an HSTS header on the base domain for HTTPS requests:- The max-age must be at least 31536000 seconds (1 year).- The includeSubDomains directive must be specified.- The preload directive must be specified.- If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (rather than the page it redirects to).
You’ll find more information at hstspreload.org.
This security header stops certain kinds of exploits that can happen, for example, through malicious user-generated content.
The “sniffing” allows a browser to download the web page elements and correctly render them, in particular in situations when the metadata the browser needs to render the element is missing.
Sniffing allows the browser to figure out what the element is (an image, text, etc.) and then render that element.
The X-Content-Type-Options header can stop that and other related attacks by disabling the ability of browsers from “sniffing” for the content type.
The X-Frame-Options security header helps stop click-jacking attacks.
Mozilla describes Click-jacking as:
“…the practice of tricking a user into clicking on a link, button, etc. that is other than what the user thinks it is.
This can be used, for example, to steal login credentials or to get the user’s unwitting permission to install a piece of malware.”
The X-Frame-Options header works by preventing a web page from being rendered within an iframe, for example.
It prevents more than just iframe-based attacks, though.
Microsoft defines frame sniffing in this way:
“Framesniffing is an attack technique that takes advantage of browser functionality to steal data from a website.
Web applications that allow their content to be hosted in a cross-domain IFRAME may be vulnerable to this attack.
The X-Frame-Options header can be used to control whether a page can be placed in an IFRAME.
Because the Framesniffing technique relies on being able to place the victim site in an IFRAME, a web application can protect itself by sending an appropriate X-Frame-Options header.”
The Open Web Application Security Project (OWASP) provides a helpful explanation of click-jacking attacks:
“…imagine an attacker who builds a web site that has a button on it that says “click here for a free iPod”.
However, on top of that web page, the attacker has loaded an iframe with your mail account, and lined up exactly the “delete all messages” button directly on top of the “free iPod” button.
The victim tries to click on the “free iPod” button but instead actually clicked on the invisible “delete all messages” button.
In essence, the attacker has “hijacked” the user’s click, hence the name “Clickjacking”.”
The X-Frame-Options header is important for protecting your site visitors as well as your site’s reputation.
The OWASP web page on click-jacking goes on to describe how Adobe Flash fell victim to a click-jacking attack that allowed hackers to take control of microphones and cameras, thus cementing Flash’s negative reputation as a security nightmare.
Becoming known across social media and the greater Internet as a security hazard is bad for business.
The X-Frame-Options header is a useful security measure to implement.
The purpose of a Referrer-Policy header is to allow a website publisher to control what information is sent when a site visitor clicks a link to visit another website.
When a site visitor clicks a link and lands on another site, the visitor’s browser provides information about what web page sent that visit.
When you look at your server logs the referrer information is sent that tells what sites sent visitors.
However, there are some situations where the URL of the site referring a visitor to another visitor could contain sensitive information which could be leaked to a third party.
How the Referrer-Policy works is by limiting how much information is sent after a site visitor clicks a link.
A website publisher can choose to send no information as to the referrer, they can choose to send just the domain name or they can send the entire URL string.
There are eight directives that can be sent using the Referrer-Policy header:
- Referrer-Policy: no-referrer.
- Referrer-Policy: no-referrer-when-downgrade.
- Referrer-Policy: origin.
- Referrer-Policy: origin-when-cross-origin.
- Referrer-Policy: same-origin.
- Referrer-Policy: strict-origin.
- Referrer-Policy: strict-origin-when-cross-origin.
- Referrer-Policy: unsafe-url.
A common referrer policy setting is Header “no-referrer-when-downgrade” which means that referrer information will be sent to trustworthy URLs that are on HTTPS but that no referrer information will be sent to untrusted HTTP websites.
It is important to note that the referrer policy setting will not affect affiliate links.
The referrer information is coded within the landing page URL, thus the referrer information and earnings are recorded by the merchant receiving the affiliate referral.
How To Implement Security Headers
There are multiple ways to set security headers, and one popular way is with an .htaccess file.
A benefit of using the .htaccess file is that it saves a publisher from downloading another plugin.
Poorly coded plugins can become a security risk, so minimizing the number of installed plugins can be useful.
Important: Every security header implementation is going to be different according to the specifics of each website, especially the Content-Security-Policy (CSP).
WordPress Plugins For Setting Security Headers
There are some popular plugins that are already installed on millions of websites that come with the option for setting security headers.
If you already have these plugins installed, then the option for using a plugin rather than fussing with an .htaccess file is there for those who would prefer the convenience.
Really Simple SSL Pro
Over five million websites already have Really Simple SSL installed.
Upgrading to the reasonably priced pro version provides the option for setting up to eight security headers the easy way.
The 100% free WordPress Redirection plugin has been around for over ten years and is installed on over 2 million websites.
This plugin allows you to choose from many different preset security headers in addition to the top five listed in this article.
Preset means that you can choose from the standard directives.
According to the Redirection WordPress download page:
“ADD HTTP HEADERS
HTTP headers can be added to redirects or your entire site that help reduce the impact of redirects or help increase security. You can also add your own custom headers.”
Additionally, the Redirection plugin allows you to custom craft your own security headers if there’s something there you don’t find.
The Redirection plugin makes it easy to successfully install the top five security headers:
Set Security Headers With Cloudflare
Cloudflare has a way to set security headers using their Cloudflare workers.
Cloudflare also has another support page with directions:
To attach headers to Cloudflare Pages responses, create a _headers plain text file in the output folder of your project.
It is usually the folder that contains the deploy-ready HTML files and assets generated by the build, such as favicons.
The _headers file should not always be in the root directory of the repository. Changes to headers will be updated to your website at build time, so make sure you commit and push the file to trigger a new build each time you update headers.
Header rules are defined in multi-line blocks.
The first line of a block is the URL or URL pattern where the rule’s headers should be applied. On the next line, an indented list of header names and header values must be written…”
How To Check Security Headers
Security headers are easy to check.
SecurityHeaders.com offers a free security header checking service.
Web auditing software Screaming Frog also has the option for checking headers which is available in the Security Tab.
Make Security Headers A Part Of Your SEO Audits
Security headers are something that many publishers or SEO experts might not consider.
But security headers are important and should be top of mind in every site audit, whether that audit is conducted in-house or by third-party SEO site auditing.
Website security is an SEO-related issue because failure to mitigate negative security issues can reverse every ranking-related success.
A negative reputation can hurt rankings and sales.
Loss of search visibility causes devastating losses.
Implementing security headers is relatively easy, it should be among the top boxes to check when publishing any website.
- WordPress Security: 16 Steps to Secure & Protect Your Site
- HTTPS As A Google Ranking Factor: What You Need to Know
- WordPress SEO Guide: Everything You Need to Know
Featured Image: Monkey Business Images/Shutterstock