Security headers check
HTTP security headers tell the browser how to protect your visitors. This free scan reads your live response and shows which protective headers are present, which are missing, and what each one is for.
Free, read-only, no signup. See our methodology.
In short
Security headers are short instructions your server sends with every page. The right set forces HTTPS, blocks clickjacking, stops the browser guessing file types, and limits what scripts can do. Our scan reports which ones your site actually sends.
The headers this scan detects
The scanner reads the final response after any redirects and reports on each header below. Missing headers are flagged so you know where the gaps are.
| Header | What it does |
|---|---|
Strict-Transport-Security | HSTS forces browsers to connect over HTTPS only, even if someone types http://. |
Content-Security-Policy | Controls which sources of scripts, styles and other resources the browser will load — the strongest defence against cross-site scripting. |
X-Frame-Options | Stops your pages being embedded in a hostile frame. CSP frame-ancestors does the same job in a modern policy. |
X-Content-Type-Options | nosniff tells the browser not to second-guess a file’s declared type, closing a class of MIME-sniffing attacks. |
Referrer-Policy | Controls how much of your URL is shared with other sites when a visitor clicks away. |
Permissions-Policy | Restricts powerful browser features such as camera, microphone and geolocation. |
Why security headers matter
Most attacks against small sites don’t rely on exotic exploits — they rely on defaults being left open. Without HSTS, a visitor on a hostile network can be quietly downgraded to plain HTTP. Without a Content-Security-Policy, a single injected script can run with full access to the page. Without clickjacking protection, your login form can be layered invisibly over an attacker’s page. Each header is a one-time configuration change that removes a whole category of risk, which is why they carry real weight in the scan score.
How to fix missing headers
- Add HSTS once your HTTPS redirect is solid: start with a modest
max-age, confirm nothing breaks, then raise it. Only addpreloadwhen you are certain every subdomain is HTTPS. - Deploy a Content-Security-Policy gradually. Begin in report-only mode to see what would break, tighten the policy, then enforce it.
- Set the quick wins in one go:
X-Content-Type-Options: nosniff, anX-Frame-Optionsorframe-ancestorsrule, and a sensibleReferrer-Policysuch asstrict-origin-when-cross-origin.
max-age is hard to undo. Test in stages.
Header guides to go deeper
HTTP Security Headers: The Complete Checklist
Every important HTTP security header explained, what it protects against, and a copy-paste starting configuration.
Read guide →HTTP Security HeadersHSTS Explained: Strict-Transport-Security Done Right
How HSTS forces HTTPS, what the preload list means, and how to roll it out without locking yourself out.
Read guide →HTTP Security HeadersContent Security Policy (CSP) for Beginners
How CSP stops cross-site scripting, why it is hard to get right, and a safe way to deploy your first policy.
Read guide →Frequently asked questions
Which security headers does the scan check?
It reads the live response and reports on Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options or CSP frame-ancestors, X-Content-Type-Options and Referrer-Policy, and recognises Permissions-Policy when present. It also flags a Server header that leaks a version number.
Where do I add HTTP security headers?
Headers are added once in your web server or application configuration — an Nginx or Apache config block, or your framework’s middleware. They then apply to every response automatically.
What is the most important header to add first?
HSTS and Content-Security-Policy carry the most weight. HSTS forces browsers to use HTTPS, and CSP is the single strongest defence against cross-site scripting.