// HTTP
Security Headers Check
See which browser-side defences a site has switched on — and what each missing one costs.
// What HTTP security headers actually do
When a server answers a request it sends headers alongside the content. A handful of them are safety instructions: insist on HTTPS from now on, restrict where scripts may load from, refuse to be embedded in someone else's page, stop guessing at content types. None of them cost anything to send, and each one removes a category of attack that would otherwise be available.
Strict-Transport-Security is the highest-value of the set. It tells the browser to refuse plain HTTP for this domain for a fixed period, closing the window in which a first request over HTTP can be intercepted and redirected somewhere else. Six months is the usual minimum — the header is worth very little with a short max-age.
Content-Security-Policy is the most powerful and the most work. It declares where scripts, styles, images and connections may come from, so that injected script has nowhere to run from. It is also the header most likely to break a working site, which is why it is normally deployed in report-only mode first and tightened once the reports go quiet. A policy containing 'unsafe-inline' still helps, but it gives up most of the protection against cross-site scripting.
The rest are one-liners. X-Frame-Options, or CSP frame-ancestors, stops clickjacking. X-Content-Type-Options: nosniff stops a browser reinterpreting an uploaded file as executable script. Referrer-Policy stops full URLs — including anything sensitive sitting in a query string — being handed to third-party sites when someone clicks away. Permissions-Policy switches off camera, microphone and geolocation for anything you embed.
A grade here measures configuration, not safety. A site with perfect headers can still have an injection bug, and a site with none may be carefully written. What the grade tells you is how much cheap defence-in-depth is currently sitting on the table unclaimed.
// Frequently asked questions
- Will adding a Content-Security-Policy break my site?
- It can, if you rely on inline scripts or third-party widgets. Deploy it as Content-Security-Policy-Report-Only first, watch what gets reported for a week or two, then switch to enforcing once the reports are clean.
- Which header should I add first?
- Strict-Transport-Security and X-Content-Type-Options. Both are a single line, neither breaks anything, and together they close off protocol-downgrade attacks and MIME confusion. Add X-Frame-Options next, then work up to a CSP.
- Do security headers help SEO?
- Not directly. Serving over HTTPS is a ranking signal; the headers themselves are not. They matter for user safety and for passing security reviews, not for rankings.
- Why does my site score badly when it is behind a CDN?
- Most CDNs and hosting platforms pass through whatever your origin sends and add nothing of their own. Cloudflare, Vercel, Netlify and the rest all let you set these headers in configuration — the defaults simply are not set for you.
- Is it safe to run this against a site I do not own?
- Yes. It makes one ordinary GET request and reads the response headers, exactly as a browser would, and never downloads the page body. It does not scan ports, probe for vulnerabilities or submit anything.