How hardened is your
web server, really?
Enter a URL — the check fetches the page and inspects which HTTP security headers your server returns: HSTS, CSP, X-Frame-Options, Referrer-Policy and more. You'll see exactly where the gaps are and what they mean in practice.
HTTP security headers — what the check inspects
The check requests your page and evaluates the HTTP response headers your server uses to tell browsers how to fend off attacks: HSTS (enforces HTTPS), Content-Security-Policy (limits which scripts may load), X-Frame-Options / frame-ancestors (prevents clickjacking), Referrer-Policy and Permissions-Policy.
These headers cost nothing, require no changes to the site's code itself, and rule out an entire class of attacks — cross-site scripting fallout, embedded fake frames, unintended data leakage via referrers. Missing headers aren't an acute hack, but they are an open flank that a few lines of server configuration can close.
The result shows each header as set, missing or problematically configured — with a short explanation of what each one prevents in practice.
Frequently asked questions
Will a Content-Security-Policy break my site?
An overly strict CSP can block inline scripts or external services. That's why you introduce it gradually: observe in report-only mode first, then enforce. The check gives you the starting point.
Where do I configure the headers?
At the hosting or server level: in the Next.js config, .htaccess, nginx configuration or your CDN (e.g. Cloudflare). It's configuration, not a rebuild of the website.
Which headers matter most?
HSTS and a Content-Security-Policy have the biggest effect. X-Content-Type-Options and a restrictive Referrer-Policy take one line each and should be standard.