This translation has not been editorially reviewed yet. The German version is authoritative. Deutsche Fassung →
Indexing
What security headers should a web server send?
Headers that hand the browser protection rules — the most important: Strict-Transport-Security (enforces the encrypted connection), Content-Security-Policy (limits where scripts may load from), X-Content-Type-Options (prevents file types from being reinterpreted), X-Frame-Options or frame-ancestors (prevents embedding in foreign pages), and Referrer-Policy (limits what's transmitted when leaving the page). Our check reads your website's response headers and names which of these protection rules are missing.
Protection rules the browser enforces
Security headers are instructions from the server to the browser: only connect encrypted. Only run scripts from these sources. Don't reinterpret file types. Don't let this page be embedded in a foreign frame. The browser enforces these rules for the visitor — so they still take effect even if something goes wrong elsewhere, a foreign script getting injected, say. Adding them happens in the server configuration and doesn't change the website itself.
Why this is a findability issue too
Search engines increasingly assess websites by trust signals, and security practice is one of them. More important still is the indirect effect: a website that foreign code gets into through a missing protection rule can be classified as dangerous by search engines and marked with warnings — the worst possible damage to visibility. The headers are the cheapest insurance against that.
What the check exactly measures
The check reads the HTTP response headers of the pages measured and matches them against the list of protection headers. The report names the missing ones — as a concrete work list for the server configuration. What's assessed is presence; fine-tuning a Content Security Policy for the specific website remains a task for technical support, since an overly strict rule can break functionality.
- Add the missing headers in the web server configuration (nginx, Apache) or the hosting provider's management panel.
- Start with the low-risk headers: X-Content-Type-Options, Referrer-Policy, and X-Frame-Options practically never break anything.
- Introduce a Content Security Policy first in observation mode (report-only), and only then switch it on for real.
- Set Strict-Transport-Security only once the entire website is permanently reachable over an encrypted connection.
FAQ
Can security headers break the website?
Most are risk-free. Two deserve care: an overly strict Content Security Policy can block embedded scripts, and Strict-Transport-Security locks visitors into the encrypted connection for a long time. That's why both are introduced gradually.
We already have an SSL certificate — isn't that enough?
The certificate encrypts the connection once it's established. The protection headers additionally govern what the browser is allowed to do with the page — they supplement encryption, but don't replace it, and aren't replaced by it.
Who sets these headers — the agency or the hosting provider?
Both happen: with your own server, it belongs in the server configuration (typically the agency or an administrator); with website-builder and managed hosting, many providers offer the headers as a setting. The report with the missing names is the right basis for either.