HTTP Security Headers: 5 Headers You Must Implement on Your Site
1 Star2 Stars3 Stars4 Stars5 Stars (3 votes, average: 4.67 out of 5)
Loading...

HTTP Security Headers: 5 Headers You Must Implement on Your Site

Everything you need to know about HTTP security headers

“Securing a website is like riding a bicycle. To keep your balance, you must keep moving.” This is what Albert Einstein’s famous bicycle quote would look like had he been a cybersecurity professional. Fortunately (or not), he wasn’t. Keeping the bicycle analogy going though, you can’t stop pedaling. The moment you do, the bicycle starts slowing down and you eventually just topple over. You don’t want that, do you?

But when it comes to riding a bicycle, not all pedal strokes are the same. Some are smooth; some are hard, some make you go shorter distances while some take you longer. Today, let’s talk about the ones that will keep your website security bicycle moving for at a brisk pace. Let’s talk about HTTP security headers.

HTTP security headers are a fundamental part of website security. Upon implementation, they protect you against the types of attacks that your site is most likely to come across. These headers protect against XSS, code injection, clickjacking, etc.

Let’s hash out HTTP security headers.

What are HTTP Security Headers?

When a user visits a site through his/her browser, the server responds with HTTP Response Headers. These headers tell the browser how to behave during communication with the site. These headers mainly comprise of metadata.

You can use these headers to outline communication and improve web security. Let’s have a look at five security headers that will give your site some much-needed protection.

1.     HTTP Strict Transport Security (HSTS)

Let’s say you have a website named example.com and you installed an SSL/TLS certificate and migrated from HTTP to HTTPS. This is good, right? That was rhetorical. It definitely is. But this isn’t where the work stops. What if your website is still available over HTTP? It would be utterly pointless, right? Many website admins migrate to HTTPS and then forget about it without realizing this. This is where HSTS enters the picture.

If a site is equipped with HTTPS, the server forces the browser to communicate over secure HTTPS. This way, the possibility of an HTTP connection is eliminated entirely.

Great, isn’t it?

Syntax:

Strict-Transport-Security: max-age=<expire-time>

Strict-Transport-Security: max-age=<expire-time>; includeSubDomains

Strict-Transport-Security: max-age=<expire-time>; preload

2.     Content Security Policy (CSP)

The HTTP Content Security Policy response header gives website admins a sense of control by giving them the authority to restrict the resources a user is allowed to load within site. In other words, you can whitelist your site’s content sources.

Content Security Policy protects against Cross Site Scripting and other code injection attacks. Although it doesn’t eliminate their possibility entirely, it can sure minimize the damage. Compatibility isn’t a problem as most of the major browsers support CSP.

Syntax:

Content-Security-Policy: <policy-directive>; <policy-directive>

3.     Cross Site Scripting Protection (X-XSS)

As the name suggests, X-XSS header protects against Cross-Site Scripting attacks. XSS Filter is enabled in Chrome, IE, and Safari by default. This filter doesn’t let the page load when it detects a cross-site scripting attack.

Syntax:

X-XSS-Protection: 0

X-XSS-Protection: 1

X-XSS-Protection: 1; mode=block

X-XSS-Protection: 1; report=<reporting-uri>

4.     X-Frame-Options

In the Orkut era, a spoofing technique called ‘Clickjacking’ was pretty popular. It still is. In this technique, an attacker fools a user into clicking something that isn’t there. For example, a user might think that he’s on the official Orkut website, but something else is running in the background. A user may reveal his/her confidential information in the process.

X-Frame-Options help guard against these kinds of attacks. This is done by disabling the iframes present on the site. In other words, it doesn’t let others embed your content.

Syntax:

X-Frame-Options: DENY

X-Frame-Options: SAMEORIGIN

X-Frame-Options: ALLOW-FROM https://example.com/

5.     X-Content-Type-Options

The X-Content-Type header offers a countermeasure against MIME sniffing. It instructs the browser to follow the MIME types indicated in the header. Used as a feature to discover an asset’s file format, MIME sniffing can also be used to execute cross-site scripting attacks.

Syntax:

X-Content-Type-Options: nosniff

 

Certificate Management Checklist

Manage Digital Certificates like a Boss

14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.

3 comments
  • Hey Jay, Thanks for the information, however, I’m trying to wrap my head around how to apply these in a WordPress environment. (Maybe a little more caffeine would help too!) Would you recommend these go in the .htaccess or in the theme header?

  • Ok, so if I am on someone’s Apache server hosting my site, that I wouldn’t have control over, I can put all those headers in my .htaccess file? Should it be the file at my root? And how can I modify it so the server details are masked? Thank you.

Leave a Reply

Your email address will not be published. We will only use your email address to respond to your comment and/or notify you of responses. Required fields are marked *

Captcha *

Author

Jay Thakkar

After graduating from university with an engineering degree, Jay found his true passion as a writer…specifically, a cybersecurity writer. He’s now a Hashed Out staff writer covering encryption, privacy, cybersecurity best practices, and related topics.