Security Headers Check
The security headers check shows which protective mechanisms are enabled on the site and which are not. This is the cheapest form of hardening: almost everything is configured on the server side and does not require changes to the code. The tool is security headers audit.
What is checked
| Header | Protects against | Importance |
|---|---|---|
| Strict-Transport-Security | Forces https: protects against connection hijacking | Medium |
| Content-Security-Policy | Limits where scripts are loaded from — the main protection against code injection | Medium |
| X-Frame-Options | Prevents embedding the site in another frame (clickjacking) | Low |
| X-Content-Type-Options | Prevents the browser from guessing the file type | Low |
| Referrer-Policy | Limits what goes to external analytics when transitioning | Informational |
| Permissions-Policy | Disables unnecessary capabilities: camera, microphone, geolocation | Informational |
Where to start
- HSTS — if the site is already fully on https, it can be enabled with a single line.
- Protection against clickjacking and type guessing — also one line, with no side effects.
- Content-Security-Policy — the most useful and the most finicky: start in report mode, otherwise you risk breaking your own scripts.
- Others — optional: these headers do not break anything and add neatness.
What headers do not do
They do not protect against hacking through vulnerabilities in the code, do not heal an infected site, and do not replace CMS updates. Their task is to narrow down the attack possibilities in the visitor's browser and reduce damage if something goes wrong. A full check is a separate scanner: see malware and backdoor analysis.
Relation to other checks
These same headers are included in the Shield report and partially in the SEO Audit. The theoretical analysis of each is in the glossary: security headers. To view the raw response headers — headers check.