Skip to content

Protective settings of the server

Does the web server send the most important security headers, and are they set effectively?

What we check

With every page the web server sends invisible additional information, the so-called HTTP headers. Some of them instruct the browser to fend off certain attacks. On the home page we check six of them:

Header Protects against
Strict-Transport-Security (HSTS) falling back to unencrypted HTTP
Content-Security-Policy injected foreign code
X-Frame-Options embedding the page on foreign pages (clickjacking)
Referrer-Policy unnecessary passing on of addresses visited
X-Content-Type-Options files being interpreted wrongly
Permissions-Policy unwanted access to camera, microphone or location

If three of the first four are missing, there is a warning. If individual ones are missing, a note. We also report weak settings: an HSTS duration under 180 days and unsafe-inline or unsafe-eval in the Content Security Policy.

Why it matters

Security headers are like the seat belts of a website. They do not prevent a mistake in the code, but they limit the damage when one happens:

  • HSTS makes sure that the browser only opens the page encrypted from then on, even if someone types http:// or follows an old link.
  • Content-Security-Policy defines from which addresses scripts may be loaded. If an attacker manages to inject code into the page, for example through a vulnerable plugin, this code is not executed.
  • X-Frame-Options prevents a fraud page from embedding the website invisibly and tricking visitors into clicks.

These headers cost nothing, slow nothing down and can usually be set up with a few lines.

How to fix it

Apache (.htaccess)

For most websites this is a good start:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Frame-Options "SAMEORIGIN"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Set HSTS only once HTTPS works reliably, also for all subdomains, otherwise visitors are locked out.

Content Security Policy

It depends on which foreign services the page includes: Google Fonts, Maps, YouTube, analytics tools. Have the agency in charge create it and test it first in the Content-Security-Policy-Report-Only mode.

WordPress

Plugins such as "Headers Security Advanced & HSTS WP" set the headers without server access. Some security and caching plugins also offer this function.

Hosting with a panel

In Plesk and cPanel additional headers can be entered in the settings for Apache or nginx. If in doubt, ask the support of the hosting provider.

How to check it yourself

Enter the address of the website on securityheaders.com. The service shows all headers set and rates them with a grade from A+ to F.

Frequently asked questions

Can these headers break something?

With the Content Security Policy, yes: if it is too strict, fonts, maps or videos no longer load. So it should be tested first with "Content-Security-Policy-Report-Only". The other headers are unproblematic.

The builder does not allow custom headers. What now?

With Wix, Jimdo or Squarespace the provider defines the headers. The provider can be asked about it, but usually it cannot be changed directly. The check then mainly shows how well the provider takes precautions.

Check a website now

We check "Protective settings of the server" and all other points in a few minutes, free and without sign-up.