CSP
Control scripts and resource origins.
Check CSP, HSTS, clickjacking, MIME sniffing and browser permission policies.
Enter a page URL, then click Check headers.
HTTP SECURITY
HTTP security headers are browser-enforced rules sent with a server response. They can restrict script sources, enforce HTTPS, prevent unauthorized framing, and reduce MIME confusion and referrer-data exposure.
Headers do not replace secure coding, dependency updates or vulnerability fixes, but they add a useful enforcement boundary in the browser.
Control scripts and resource origins.
Keep browser traffic on HTTPS.
Reduce framing, MIME and permission risks.
CDNs, reverse proxies, application frameworks and origins can all add or override headers. A deployment change can silently remove CSP, HSTS or framing protection, so the public final response needs regular verification.
CSP restricts scripts and resources, reducing the execution space available after an XSS flaw.
HSTS reduces downgrade exposure while frame-ancestors blocks unauthorized embedding.
Inspect the final public response to find differences across CDN, proxy and application layers.
The tool safely requests a public page, follows controlled redirects and analyzes six core header groups on the final response.
Block local, private and reserved addresses, resolving again after every redirect.
Record status, response IP, redirects and the security headers actually delivered.
Check CSP sources, HSTS duration, framing controls and standardized values.
Separate missing and weak settings while preserving important deployment cautions.
The score compares these six configurations; it is not a vulnerability scan or a search-ranking score. Fix HTTP, CSP, HSTS, framing and nosniff gaps first, then tighten policies around real application needs.
Core controls are mostly complete; verify that policies still match actual resources and workflows.
Some headers are present, but important gaps or weak settings remain.
Most core controls are missing or the page still uses HTTP; establish a baseline first.
There is no evidence that CSP or Permissions-Policy alone raises rankings. HTTPS, reliable access and fewer security incidents support long-term crawlability and trust, but headers are not a ranking trick.
An overly strict policy can break payments, sign-in, analytics, ads and third-party resources. Start with Report-Only, introduce nonces or hashes, and enforce gradually.
No. Preload has long-lived effects and is difficult to undo quickly. Confirm that the main domain and every subdomain will support HTTPS permanently before applying.
Modern browsers prefer CSP frame-ancestors, which supports precise allowed origins. Keep DENY or SAMEORIGIN as a legacy fallback when needed.
It is a defense-in-depth and least-privilege control, not proof of an active vulnerability. Restrict capabilities according to the features the site actually uses.
Continue with SSL, page response, metadata and blacklist checks.
Check certificate validity, hostname, trust chain and TLS protocol.
Check final status, redirect chains and search-related headers.
Check search snippets, Open Graph and Twitter Cards.
Check domain or IP reputation database signals.