Security

Which security headers is your site actually sending?

Security headers are the cheapest hardening available — a few lines of server configuration that block entire classes of attack. Most sites send none of them. This tool reads your live response headers and grades what is there.

We make one request and read the response headers. Nothing is stored.

The headers reported are read from the actual HTTP response your server returned to us. Grading follows OWASP's secure headers guidance. A missing header is reported as missing; a header with a weak value is reported as weak, with the specific reason.

The guide behind this tool HTTP Security Headers: What Each One Actually Does Six headers that block entire classes of attack, in priority order — what each one does, what breaks if you get it wrong, and the two you should stop sending. Read the guide · 6 min read →

What this tool checks

Eight headers read from your live HTTP response, graded against OWASP guidance — including two you should be removing.

  • Strict-Transport-Security

    Whether HTTPS is enforced, for how long, and whether subdomains are included.

  • Content-Security-Policy

    Present, enforcing or report-only — and whether 'unsafe-inline' has quietly removed most of its value.

  • Clickjacking protection

    X-Frame-Options or CSP frame-ancestors. Without either, your pages can be framed under a decoy.

  • X-Content-Type-Options

    One value, no configuration, no downside. Its absence is the easiest fix on this page.

  • Referrer-Policy

    Whether full URLs — including anything in query strings — leak to every site your visitors click through to.

  • Permissions-Policy

    Which browser features are available to every script on the page, including third-party ones.

  • Version disclosure

    Server and X-Powered-By headers that advertise your exact software version to vulnerability scanners.

  • Obsolete headers

    X-XSS-Protection enabled a filter that was removed for introducing vulnerabilities of its own.

How to read your result

Start with the three that cannot break anything: X-Content-Type-Options, X-Frame-Options and Referrer-Policy. Each is one line, safe on essentially any site, and deployable together this afternoon.

Then remove what should not be there. Deleting X-XSS-Protection and suppressing version headers takes minutes.

HSTS next, carefully. It is a commitment browsers enforce and you cannot quickly withdraw. Confirm every subdomain serves HTTPS, then raise max-age in stages rather than jumping to a year.

CSP last, in report-only mode first. It is the most effective header here and the only one that can break your site. Collect violations for two to four weeks, whitelist what is legitimate, then enforce.

An honest note: none of this is a ranking factor. The reason to do it is that a compromised site loses rankings very fast once Google flags it — and by then you are fixing something far more expensive than a config file.

What each header does

Strict-Transport-Security (HSTS)

Tells the browser to only ever connect over HTTPS to this domain, for a stated period. It closes the window where a first request over HTTP could be intercepted and downgraded.

Strict-Transport-Security: max-age=31536000; includeSubDomains

Start with a short max-age while you confirm every subdomain works over HTTPS. Once you set a year with includeSubDomains, you have committed — browsers will refuse plain HTTP to any subdomain until it expires.

Content-Security-Policy (CSP)

The most powerful and the most work. It declares which sources of scripts, styles, images and connections the page is permitted to load, which shuts down most cross-site scripting even when an injection succeeds.

The reason so few sites have one is that a strict CSP breaks inline scripts, and most sites have inline scripts everywhere. The practical path is to deploy in report-only mode first, collect violations for a couple of weeks, then enforce.

X-Frame-Options

Stops your pages being embedded in an iframe on someone else's site, which is how clickjacking works — an invisible frame over a page the victim thinks they are clicking.

frame-ancestors in CSP supersedes it, but sending both costs nothing and covers older browsers.

X-Content-Type-Options: nosniff

One value, no configuration, no downside. It stops browsers from guessing a file's type when the declared type looks wrong — the mechanism behind attacks where an uploaded file is served as an executable script. There is no reason not to send it.

Referrer-Policy

Controls how much of the current URL is sent when a visitor clicks through to another site. Without it, full URLs — including any tokens or identifiers in query strings — leak to third parties. strict-origin-when-cross-origin is the sensible default and is now the browser default too.

Permissions-Policy

Declares which browser features the page may use: camera, microphone, geolocation, payment. Denying what you do not use limits the damage a compromised third-party script can do.

Headers you should not send

X-XSS-Protection is obsolete. The filter it enabled was removed from Chrome and Edge because it introduced vulnerabilities of its own. Sending it does nothing useful and signals a configuration copied from a decade-old tutorial.

Server and X-Powered-By advertise your exact software version, which is free reconnaissance for anyone scanning for known vulnerabilities. Suppress them.

Frequently asked questions

Do security headers affect SEO?

Not directly. HTTPS is a lightweight ranking signal and HSTS supports that, but no search engine ranks on CSP. The reason to implement them is that a compromised site does lose rankings — fast and hard, once Google flags it as hacked or serving malware.

Is CSP worth the effort?

For a site handling logins, payments or personal data, yes. For a brochure site, the effort-to-benefit ratio is worse, and you get most of the value from the other five headers, which are one-line changes. Be honest about which you are.

Will these headers break my site?

CSP can, which is why report-only mode exists. HSTS is a commitment you cannot quickly reverse, so raise max-age gradually. The rest — nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy — are safe to add immediately for almost every site.

How do I add them on shared hosting?

Through .htaccess if you are on Apache or LiteSpeed, which covers most shared hosting including Hostinger. A `<IfModule mod_headers.c>` block with a `Header always set` line per header. Nginx uses `add_header` in the server block instead.

Other free tools

SEO & Speed Audit

Real Core Web Vitals from Google's API, plus live on-page checks against your actual HTML.

Tell us what you are trying to grow.

One team. Three offices. Twenty-six languages. Send us the problem and you get a senior answer — not a sales script.

Get a proposal → Message us now

A written proposal within one business day, in your language.