Security headers

Check the security headers on a live page

We read the headers the server already sends with the page. Nothing is injected, and we do not send a browser exploit to prove a header is missing.

Each gap is tagged Urgent, Important, or Nice to fix, based on severity. A missing Content-Security-Policy is a medium finding. A public site still on plain HTTP is high.

What this scan actually checks

• Content-Security-Policy.
• Strict-Transport-Security when the final URL is HTTPS.
• X-Content-Type-Options: nosniff.
• Clickjacking: X-Frame-Options or a CSP frame-ancestors directive. Either one is enough.
• Referrer-Policy.
• Permissions-Policy, as an informational note when it is absent.
• Access-Control-Allow-Origin: *. If credentials are also allowed, that is a separate, higher finding.
• Cookie flags on each Set-Cookie: Secure, HttpOnly, SameSite. We do not flag a response that sets no cookies.
• HTTP on a public host. HTTP on a local or private host is only a note, and the hosted scanner does not fetch those addresses anyway.

What it does not check

• We look at the document response and the small set of other responses this scan fetches. A header that exists only on an API route we never request will not appear.
• We do not grade the quality of a CSP beyond whether it is present and whether it sets frame-ancestors. A policy of unsafe-inline can still be in place.

What to do with the result

• Add the missing headers at the host or in the framework's header config, then scan again. A credit from the $29 pack can pay for that re-check.
• Turn on HSTS only after HTTP already redirects to HTTPS.

Questions

All guides →