Free security tool
Grade a website’s Content-Security-Policy directive by directive, read its HSTS, cookie and CORS configuration, and score the response out of 100.
CloudSpex explains what each checked header does, why it matters and what should be changed when it is not detected.
HTTP security headers are instructions sent with a website response. They can help browsers apply protections against common classes of browser-side risk, but a header being present does not by itself prove that its policy is suitable for every application.
Parsed directive by directive and graded A to F: unsafe-inline, unsafe-eval, wildcard and scheme-wide sources, a missing default-src fallback, open object-src, frame-ancestors, nonce or hash usage and upgrade-insecure-requests.
max-age, includeSubDomains and the preload token, with an explicit statement of what preload eligibility can and cannot be confirmed from one response.
X-Frame-Options and the CSP frame-ancestors directive together, because either one controls framing and requiring both would be a false positive.
Whether nosniff is sent, which stops the browser guessing a response type and treating an upload as script.
Whether an explicit policy limits how much of the URL is sent to third-party sites.
Whether powerful browser features are restricted rather than left at their defaults for the page and any embedded frame.
The cross-origin isolation headers, reported with the context that COEP breaks pages when enabled without preparation and is not a baseline requirement.
Secure, HttpOnly and SameSite for every cookie the response sets. No cookies means no findings, and HttpOnly is a warning rather than a failure because some cookies must be readable by the front end.
Access-Control-Allow-Origin, credentials, methods and headers as they appear on a single response. Origin reflection is not claimed, because it cannot be proven without sending different origins.
Every finding carries a severity, an explanation of the risk and a concrete remediation step, and the response is scored out of 100 using fixed penalties so the same configuration always produces the same score.
The most common problem is not a missing header but a policy that looks protective and is not. A Content-Security-Policy with script-src 'unsafe-inline' permits exactly the inline code an injected script needs. A wildcard in script-src removes the restriction entirely. A policy published only as Content-Security-Policy-Report-Only blocks nothing at all. HSTS with a short max-age leaves the downgrade window open. A session cookie without Secure travels over plain HTTP. This page reads the values rather than only checking whether the header is there.
Header values must fit the application and its deployment, so context decides severity here rather than a fixed checklist. A wildcard is high risk in script-src and routine in img-src. unsafe-inline is ignored by modern browsers when a nonce is also present, so it is reported as information in that case rather than as a weakness. A cookie without HttpOnly may be intentional. Findings that cannot be measured from one read-only response — CORS origin reflection, full HSTS preload eligibility — are stated as not assessed rather than guessed.
Shows the available header state on the current public response.
Helps track HTTP security headers and related website configuration changes after deployments or proxy updates.
HTTP security headers tell browsers how to handle a website in ways that can reduce common security risks. They are sent by the website response and should be reviewed alongside the rest of the website configuration.
It reads the final safe HTTPS response and evaluates Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the three cross-origin policies (COOP, COEP, CORP). It also analyses the CSP directive by directive, reads HSTS max-age, includeSubDomains and preload, checks the Secure, HttpOnly and SameSite flags on any cookie the response sets, and reports the CORS headers it can see.
Content-Security-Policy tells the browser which sources it may load content from. It is the single most effective header against injected scripts, and it is also the easiest to publish in a form that looks protective but is not. This page grades it from A to F based on what the directives actually allow.
The grade comes only from the CSP findings, using fixed penalties, so the same policy always produces the same grade. A means no unsafe directive was found. B is a small gap such as a missing default-src fallback. C covers unsafe-eval or an open object-src. D covers unsafe-inline on scripts. F means no policy at all, or several unsafe directives together. A report-only policy is capped at C because it blocks nothing today.
No, and treating it that way is a common false positive. If script-src also contains a nonce or a hash, browsers supporting CSP Level 3 ignore unsafe-inline entirely, so it is only a fallback for very old browsers. This page reports that case as information rather than a weakness, and only flags unsafe-inline as high risk when nothing neutralises it.
No. It depends on the directive. A wildcard in script-src, object-src or default-src removes the restriction on code execution and is reported as high risk. A wildcard in img-src, font-src or media-src is common on sites serving CDN or user media and cannot execute code, so it is reported for awareness only.
Strict-Transport-Security is an HTTPS response header that instructs supporting browsers to use HTTPS for a period of time. It should be configured only after confirming the site is fully available over HTTPS.
Not definitively, and it does not claim to. The preload list also requires the site to redirect HTTP to HTTPS and to own the apex domain, neither of which can be confirmed from a single response. When the header conditions are met, this page says the domain is potentially eligible; when the preload token is present but the other header conditions are not, it says not fully assessed.
Neither is treated as an automatic failure. If the response sets no cookies, no cookie findings are produced at all. HttpOnly is reported as a warning rather than critical because some cookies are deliberately readable by the front end. A cookie without Secure, or SameSite=None without Secure, is a genuine problem and is reported as such.
No. Reflection can only be proven by sending different Origin headers and comparing the responses, which this read-only check does not do. It reports the CORS headers present on a single response, flags Access-Control-Allow-Origin: * — and flags it as high risk when combined with credentials — but never claims a reflection vulnerability it has not measured.
No. A header can be present with a value that is not suitable for every application. That is exactly why this page reads the values rather than only reporting presence.
Nothing is guessed. If a safe HTTPS response cannot be retrieved, no score is produced and every header is shown as not measured rather than missing. An unreachable site never scores 100 and never scores 0.
Yes. This is a limited, read-only public check that uses the same protected CloudSpex Free Scan flow.
No. CloudSpex reads a public HTTPS response only. It does not change website files, DNS, headers or any other configuration.
Run a check after deployments, CDN or proxy changes. Continuous monitoring can help detect unexpected configuration changes between manual checks.
Add your domain to CloudSpex to monitor HTTP security headers and related website configuration changes.
Start Monitoring Free Check Another Website