7 Important HTTP Security Headers for the Security of your Website Visitors

Safety is usually something to think about after something bad has happened for the first time. Anyone who has ever lost passwords suddenly only secures them encrypted and whoever shatters his database suddenly makes daily updates. Something always has to happen first so that time and money are invested in safety.

With websites you can not afford such negligence anymore, because what is insecure, damages in case of doubt the own visitors. It is best to protect it and this is done, among other things with the security headers.

These HTTP security headers enable, roughly speaking, security features in the browser that are not used without explicit use of the headers.

7 important HTTP security headers

Incidentally, the headers are not in the head section, which is at the top of a website, but are direct responses from the server given via HTTP. Therefore, such headers are set via the .htaccess file.

Please make a copy of your .htaccess file before you can restore it if needed.

X-Frame-Options

A well-known standard is X-Frame Options. This determines whether the website can be integrated via iframe or not. If hidden in a malicious page, the browser prevents it.

For X-frame options, there are the following commands.

To completely ban embedding as an iframe:

Header always set X-frame options "DENY"

Allow embedding only on itself:

Header always set X-Frame-Options "SAMEORIGIN"

Referrer Policy

This security header can be used to deactivate the referrer that is normally sent. Meaning: If you visit xyz.de and click on a link to abc.de, abc.de would see the referrer, so you can understand that you have just come from xyz.de.

In times of DSGVO and data protection , no one really wants to transfer such data anymore. You can stop this with the following command:

Header set referrer policy "no-referrer"

However, it may be that some affiliate programs need the referrer to properly track your conversions. Even if most people use other techniques today, you should check it out.

X-Content-Type-Options

It may happen that there is a file on the server whose extension and type are unclear. If so, the browser checks the so-called Content-Type header. If this is missing, the browser simply advises the type of file, which can be dangerous, because theoretically attackers could dump image files that are actually HTML files and so on.

The command below prevents the browser from automatically selecting the type if the file type is not clear:

Header set X-Content-Type-Options nosniff

X-XSS-Protection

This Secutiy header prevents Reflective Cross-Site Scripting. This code is introduced via URL or POST parameters, which is then reflected to the user.

But that can be easily prevented with the following command:

Header set X-XSS protection "1; mode = block"

Strict Transport Security

The HTTP Strict-Transport-Security header ensures that there are no more requests without HTTPS. In essence, the browser is therefore said that the website requires HTTPS. So if someone tries to use HTTP or attacks with corresponding links, the browser automatically redirects to the HTTPS version of the website, which makes such attacks impossible.

The HTTP Strict-Transport-Security header works in a similar way as a cache function, because it determines that a page can be reached for several months (period of time freely selectable), only via HTTPS. And only via HTTPS. Check in advance if everything is working properly.

Header set Strict-Transport-Security "max-age = 31557600" env = HTTPS

Content Security Policy

The content security policy header is a little complicated. It can be used to specify which sources are suitable for which file types. Thus, it can be determined that the CSS files may only come from their own domain, so external CSS files are ignored. The same applies to Javascript or frames.

Basically like a kind of firewall that blocks everything that was not explicitly allowed. However, there are problems with inline code, which is often the basis for cross-site scripting attacks, so it can be quite difficult to properly configure the Content-Security-Policy header.

If you want, you can read it here in the topic and then assemble its own header. Unfortunately there is no universal solution here, because it depends on the respective website.

Feature Policy

The feature policy is already easier. This allows you to completely disable browser features that are in any way relevant to privacy or security.

These include the webcam, the microphone, the location function or payment APIs, such as Apple Pay. With the feature-policy header, this can be completely disabled so that there is no access at all.

This protects your users from possible attacks on personal data, because even if an attack takes place or malicious code can be integrated, there is no access to these sensitive functions.

But that is a bit more individual, which is why interested people have to read a bit. You can do that here , among other things , where the feature-policy header is quite well described and explained.

This is how you use the HTTP Security headers

Which headers are there and what they are responsible for, the article has now shown you. If you use an Apache HTTP Server (standard on most hosters) you can copy the entries to your .htaccess. From now on they are activated and considered accordingly.

Whether the various HTTP security headers work correctly, you can test more with this tool . Everything that is green has been correctly integrated, everything that is red or yellow may require further control.

Security and google ranking

Which HTTP security headers you use will be up to you in the end. Personally, lately I have been playing around with the features a lot, also to find out if Google takes security into account or rewards it in any way. Although I did not notice that, in principle, secure pages are important and malicious code would definitely be a problem, which is why the HTTP security headers are used primarily as a prevention.

The only two headers that I think are optional and not always that easy to use are the content security policy and feature policy headers. Much can go wrong here, since inline code is often classified as unsafe, but has become relatively normal for many. This is the configuring fumble and a mistake or a new plugin, often requires a new setting.

Providing a little security is now part of the webmaster experience, so I hope I could explain to one novice or another why the HTTP security headers are important.

Leave a Reply

Your email address will not be published. Required fields are marked *