Basic HTTP Header you should use for your website

Most content management systems (CMS) and web-frameworks ship with a number of default HTTP headers that are set automatically without requiring manual configuration of some sort. Depending on the system or framework, some headers might not be up-to-date. Or, some security critical headers might even be missing.

Learn in this article what HTTP headers you should set and configure correctly, to make sure your site remains protected.

Understandably, the authors of said frameworks and content management systems are focused on providing the best user experience for their specific use case. Security, often, is an afterthought. Something that is brought up once in a while but not regarded as a permanent priority or thought.

However, it is important to ensure that all pages of your website adhere to, at least, a basic level of security. For that, setting the right HTTP headers can help greatly. The web is not a static space. There are new headers introduced from time to time. Recommendations change. Something previously regarded as correct might turn out to be harmful several years later.

Let's take a look at which HTTP header you can set on your web server to help secure the users connecting to your service.

Content-Security-Policy (CSP)

The Content-Security-Policy header is used to specify the origins of content that is allowed to be loaded. It is a more complex header, but very powerful when guarding against cross-site scripting attacks and other injection attacks. It is widely supported by all major browsers and can therefore be used without worry. Setting up the CSP can be a challenge for non-technical users. There is great documentation on the policy in the respective guide by Mozilla. Our HTTP Header check also checks if your page has this header set, check it out.

Strict-Transport-Security (HSTS)

You should use the Strict-Transport-Security header to inform the browser that all requests to your site should be upgraded to HTTPS. Use the includeSubDomains and preload directive, if you can, and set a high max-age, like two years. For this header to make sense, you have to already use and support HTTPs, of course. This should be a no-brainer. HTTPS is considered the standard all across the web. Since 2014 Google is using HTTPS as a ranking signal. So if you are not using HTTPS, not only are you not in a good state security-wise, but you are also missing out on ranking opportunities in Google search. This header is often abbreviated as HSTS.

You might already have an HTTP redirect configured on your server. An HTTP redirect, in this context, refers to the server redirecting all traffic from HTTP to its HTTPS equivalent. This is good and better than enabling your users to view your content over both protocols, but setting the HSTS header is still more secure. Since the server needs to first receive the HTTP request to then redirect it to HTTPS, often via an HTTP 301 status code redirect, the request is, initially, still vulnerable to man-in-the-middle attacks. After setting the Strict-Transport-Security HTTP header, the browser wouldn't attempt to connect via HTTP and would opt for HTTPS initially instead, therefore eliminating this attack vector.

Since 2021, Chrome is HTTPS-first and will attempt to connect via HTTPS, before attempting HTTP. For example, if a user just types alythus.com to address a resource, Chrome will, like all other modern browsers, attempt to complete it to a full URL, and, since 2021, it will first try a request via HTTPS. This improved security greatly, but you should still include the HSTS header for protecting all clients. A user might try to connect explicitly via HTTP. To signal to the browser of that user, i.e., the client, should use HTTPS for their request, set the Strict-Transport-Security header, and the browser will honor this header on future requests.

X-Frame-Options

Another important security-related HTTP response header is the X-Frame-Options header. This header is used to indicate whether a browser should be allowed to render a page in a <frame>, <iframe>, <embed> or <object> element. There is some overlap with the Content-Security-Policy http header, since, using the frame-ancestors directive of the CSP header, you can achieve more extensive options than offered by the X-Frame-Options header. However, setting the X-Frame-Options header is still important for older browser versions, which might not yet correctly support the CSP header. Also, if you only want the very basic version of, for example, blocking your page from being rendered in an iframe element, the X-Frame-Options options suffices. For the X-Frame-Options header to take effect, it has to be set as an HTTP header, not as some developers do, via a meta-tag!

These are only some of the relevant HTTP headers you should set on your server for each and every response. To check other relevant security headers, take a look at our Free HTTP Security Header Check. For a more comprehensive analysis of your website, sign up today.