Reads the live response headers and grades them against the OWASP Secure Headers Project. Try .
A few headers shut down whole attack classes
HTTP security headers are the cheapest security win there is: a handful of response headers that tell the browser to enforce HTTPS, refuse to be framed, block injected scripts and stop guessing content types. They need no application changes, yet most sites are missing several. This checker reads what your server actually sends and grades it against the OWASP Secure Headers Project, the recognised standard for what to add and what to strip.
Each header neutralises a specific attack — together they form a layered defence.
The headers that carry the most weight
Strict-Transport-Security forces HTTPS for a set period, killing SSL-stripping downgrade attacks — set a long max-age with includeSubDomains. Content-Security-Policy is the strongest defence against cross-site scripting: it controls exactly which scripts, styles and frames may load. X-Frame-Options (or a CSP frame-ancestors directive) blocks clickjacking, and X-Content-Type-Options: nosniff stops the browser second-guessing content types. The grade reflects real-world impact, so a missing HSTS or CSP costs more than a missing advanced isolation header.
Don’t forget the headers to remove
OWASP also lists headers to strip: Server, X-Powered-By and friends leak your software and version, handing attackers a target list; and the old X-XSS-Protection header is deprecated and best set to 0. This tool flags those too. To confirm the certificate behind the HTTPS, pair this with the SSL checker; for email-side security, the Email Security Checker.
🛡️ Want a full hardening pass? Servnet reviews headers, TLS, CSP and the wider attack surface as part of managed cyber security.
Security headers — common questions
What are HTTP security headers?
They’re response headers a web server sends that instruct the browser to behave more safely — forcing HTTPS (HSTS), restricting what scripts can run (Content-Security-Policy), blocking framing (X-Frame-Options), stopping MIME-sniffing (X-Content-Type-Options) and more. Set correctly, they shut down whole classes of attack with no code changes.
What does this checker grade against?
It fetches your site’s live response headers and grades them against the OWASP Secure Headers Project (OSHP) — the community standard for which headers to add and which to remove. You get an A–F score, a per-header verdict (pass / warning / fail), the exact value to set, and a note on any information-leaking headers (like Server or X-Powered-By) you should obscure.
My site looks secure in Chrome — why does this flag missing headers?
A padlock only means the connection is encrypted; it says nothing about these headers. And browsers are lenient — Chrome can paper over a missing intermediate or tolerate an absent header. This tool reports exactly what your server sends, which is what security scanners, auditors and stricter clients actually see.
Which header matters most?
For most sites, Strict-Transport-Security (HSTS) and a Content-Security-Policy carry the most weight — HSTS removes the downgrade-to-HTTP attack surface, and CSP is the strongest single defence against cross-site scripting. X-Frame-Options (or a CSP frame-ancestors directive) closes clickjacking. The grade weights them accordingly.
How do I add a Content-Security-Policy without breaking my site?
Start with Content-Security-Policy-Report-Only and a reporting endpoint: the browser reports what *would* be blocked without actually blocking it. Tune the policy until the reports are clean, then switch to the enforcing header. Avoid unsafe-inline — use per-request nonces or hashes instead.
Should I remove the Server and X-Powered-By headers?
Yes — they reveal your web server and framework (and often the version), which helps attackers target known vulnerabilities. OWASP recommends removing or obscuring them. This checker flags them if present. It also flags the deprecated X-XSS-Protection header, which modern browsers ignore.
Does it store the sites I check?
No. The check fetches the target’s response headers server-side, grades them and returns the result; we don’t log the URLs. Only public domains are supported (not IPs or internal hostnames).