‹ All tools

Website security headers

With every response, a server can tell the browser what must not be done with your site: do not embed it in a frame, do not run foreign scripts, do not fall back to an unencrypted connection. This is the only check of the five that is fixed entirely on the server, usually in a quarter of an hour.

The domain on its own is enough. An address pasted from the browser works too.

What exactly we check

  • Strict-Transport-Security and how long it applies
  • Content-Security-Policy
  • Framing protection (X-Frame-Options or frame-ancestors)
  • X-Content-Type-Options
  • Referrer-Policy and Permissions-Policy
  • Cookies: the Secure, HttpOnly and SameSite flags
  • Headers that announce the server and language version

We assess presence and a sensible value, not the content of a policy. Judging a CSP rule itself requires knowing the site.

How to read the result

No Strict-Transport-Security

A redirect from http to https only protects the second visit. The first one, typed by hand into the address bar, can be intercepted. HSTS tells the browser to go straight to https without asking.

No Content-Security-Policy

This is the most laborious item on the list and the only one you cannot paste in without testing. In exchange it is the only header that genuinely stops a script injected into your page.

The page can be embedded in a frame

Without protection, someone embeds your page on their own site and lays invisible buttons over it. The visitor clicks something they cannot see, and the browser performs the action on your site.

Cookies without Secure and HttpOnly

A cookie without Secure can travel over an unencrypted connection, and without HttpOnly any script on the page can read it. For a session cookie that means a hijacked logged-in session.

The server announces its version

A header carrying the server or language version is a direct hint about which vulnerabilities to try. Hiding the version fixes no hole, but it stops advertising one.

Most common causes

Default hosting configuration

No popular server sends these headers by default. Their absence is not an administrator’s mistake, only a sign that nobody has got round to it yet.

Headers set on the home page only

A rule added to one configuration block may not cover subpages, static files or error responses. It is worth checking several addresses, not just the root.

A plugin instead of server configuration

Headers added by a plugin disappear when the page is served from cache or when the plugin is switched off. Their proper home is the server configuration.

Questions and answers

Do security headers affect search rankings?

Not directly. Search engines favour https rather than individual headers. The effect is indirect: a site taken over by a foreign script loses its positions very quickly.

Can a CSP break my site?

Yes, if you deploy it straight into blocking mode. That is why you start in reporting mode, collect the reports and only then switch enforcement on.

Where is this configured?

In the server configuration (nginx, Apache) or at the proxy in front of it. For most sites it is a few lines in one file and a service restart.

Do you watch this continuously?

Paid plans watch changes in what the site returns and what it links to. The free plan covers the site pulse, the certificate and the domain.

You checked once. We check every five minutes.

The free plan watches your home page, the SSL certificate and the domain expiry date. No card, no expiry date on the plan itself.

  • A pulse check every 5 minutes, with a second check confirming an outage
  • A warning before the certificate and the domain expire
  • Email notifications with no limit
  • Seven days of statistics, one account
Start free monitoring

How we watch this day to day: Website security ›