Security Headers Checker

Security Headers Checker inspects six core HTTP security headers a site sends in its responses — HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. These headers let the browser defend against common web threats like man-in-the-middle attacks, clickjacking, MIME sniffing and information leakage, so checking which ones are present gives you a quick read on a site's baseline protection.

Just enter a URL and the server safely requests it, reads the response headers, and grades the site from A to F based on how many headers are present. It only reads headers — not the page body — so the check is fast and lightweight. Results are briefly cached for instant repeat checks.

What each security header does

• Strict-Transport-Security (HSTS): forces future visits over HTTPS, blocking downgrade and man-in-the-middle attacks.
• Content-Security-Policy (CSP): restricts which sources may load scripts, styles and images, reducing XSS and injection.
• X-Frame-Options: prevents the page from being embedded in another site's frame, stopping clickjacking.
• X-Content-Type-Options: with nosniff, stops the browser from guessing MIME types and mis-executing content.
• Referrer-Policy: limits how much referrer information is sent to other sites, reducing leakage of data in URLs.
• Permissions-Policy: explicitly restricts access to browser features like camera, microphone and geolocation.

How to read the score and grade

The score counts how many of the six headers are present (n/6) and assigns a grade from A to F by ratio. All headers present earns an A; half or fewer drops to D or below. Note that the tool checks presence only, so it does not guarantee the quality of a value — for example a too-permissive CSP or a short HSTS max-age. Review each header's actual value in the table to confirm it is configured as intended.

Re-checking after changes

Headers are added in your web server (nginx, Apache), application, or CDN configuration. After a change, caching or CDN propagation may briefly serve old responses, so checking a few minutes later is more reliable than right after deploying. If you are writing a CSP for the first time, assemble it with the CSP generator, and verify cookie security attributes with the cookie security check.

Recommended header values — quick reference

This tool grades only whether a header is present, but real protection comes from the value. Below are sensible starting values that work for most sites (stricter policies need testing before rollout).

A worked interpretation

Suppose a site's response contains only three headers: strict-transport-security: max-age=300, x-content-type-options: nosniff, and x-frame-options: SAMEORIGIN. This tool reports roughly 3/6 = C. But reading the actual values in the table shows the HSTS max-age is just 300 seconds (5 minutes), so it is practically useless, while CSP, Referrer-Policy and Permissions-Policy are entirely absent. In other words the grade looks “okay,” yet the single most important defense — XSS protection via CSP — is missing. That is exactly why reading the values matters more than the score.

Common pitfall

• Setting HSTS on an HTTP response: browsers only honor the HSTS header on an https:// response. Sent over HTTP it is ignored — so redirect HTTP to HTTPS and emit HSTS on the HTTPS response.
• Mistaking grade A for “safe”: even at 6/6, a CSP containing 'unsafe-inline' makes XSS protection nearly meaningless. Presence and value quality are separate things.