Security Headers Checker

Test the HTTP security headers of any website and get a grade from A+ to F, with a plain-language explanation and a copy-ready fix for every missing header.

The DevDome server fetches the public URL (sent by POST so it stays out of request logs), follows validated redirects and reads only the final response headers. Cookie values, auth headers and query-string values are redacted before results leave the server. This is a response-policy scan, not a penetration test.

What this security headers test checks

The checker makes a server-side HTTP request with a disclosed scanner user agent, follows validated redirects to the final response, and parses the effective header values. It does not execute page JavaScript and it is not a browser. Six protections are graded on what they actually do: Strict-Transport-Security (every directive parsed, max-age=0 caught as disabled), Content-Security-Policy (parsed per policy: a framing-only CSP is never credited as script protection, and Report-Only policies are shown separately because they block nothing), frame-ancestors or X-Frame-Options with only valid values accepted, X-Content-Type-Options requiring the exact nosniff token, Referrer-Policy graded on its effective privacy behavior, and Permissions-Policy parsed as a structured policy.

It also flags information leaks like X-Powered-By and versioned Server headers, and explains X-XSS-Protection honestly: the value 0 deliberately disables a buggy legacy filter and is fine. Remediation is staged rather than absolute: CSP goes through Report-Only before enforcement, and includeSubDomains carries a warning because it can break subdomains that are not HTTPS-ready. Every result shows the observed value, its effective behavior, and why it matters.

Security headers FAQ

What are HTTP security headers?

Security headers are instructions a web server sends with every response that tell the browser how to protect the page: force HTTPS (Strict-Transport-Security), restrict where scripts load from (Content-Security-Policy), block framing (X-Frame-Options), stop MIME sniffing (X-Content-Type-Options), and limit referrer leakage and browser features. They cost nothing and block whole classes of attacks.

Which security headers should every website have?

Six matter most: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (or a CSP frame-ancestors directive), X-Content-Type-Options: nosniff, Referrer-Policy, and Permissions-Policy. This checker grades exactly those six and explains how to add each one.

What is a good security headers grade?

The grade comes from a published, versioned method (devdome-http-policy-v2): six checks with weights, scored 0 to 100 on their effective parsed values, plus hard caps: a site with no enforced script CSP on an HTML page cannot score above B, a plain-HTTP site cannot score above C, and missing clickjacking protection also caps at B. A and A+ therefore mean the core protections are actually effective, not merely present. The grade describes one response policy; it is not proof the site is secure.

How do I add security headers to WordPress?

Three ways: in your web server config (Apache .htaccess or the nginx server block), in your CDN or proxy (Cloudflare Transform Rules can add headers for free), or with a security plugin. Server or CDN level is best because the headers then cover every response, including static files.

Does Content-Security-Policy break websites?

A strict CSP can break inline scripts and third-party embeds if you deploy it blind. The safe path is to start with Content-Security-Policy-Report-Only, watch the violation reports, then enforce. The other five headers in this check are safe to add immediately on almost any site.

Do security headers affect SEO?

Indirectly, yes. HTTPS with HSTS is part of the secure-site signals Google uses, and headers that stop your site being framed or injected protect you from the kind of compromise that gets sites flagged or blocklisted, which is catastrophic for rankings.