These checks read the headers on the web responses collected during the scan. They tell you which browser-side protections are switched on. They do not execute your application, and they cannot tell you whether a given attack would succeed.
That distinction shapes everything below: these are mitigations, and a missing mitigation is not a demonstrated vulnerability.
Content Security Policy
CSP tells the browser which sources and behaviors a page is allowed to use. It is the difference between an injected script running freely and being blocked.
SSLBoard flags six situations:
- No enforced policy at all.
- An empty policy.
- A policy that is report-only, which enforces nothing.
unsafe-inlinescript allowance.eval-style script allowance.- Wildcard script sources.
Report-only is the right tool for a rollout, but it is a measurement, not a control. When a warning appears, go read the actual directives, the nonces or hashes, and what the application genuinely needs. A missing policy does not mean you have an injection bug, and a present policy does not mean you do not.
Frame protection and nosniff
Frame protection findings cover missing protection, an invalid X-Frame-Options, and its obsolete ALLOW-FROM value. An enforced CSP frame-ancestors directive also provides frame protection, so you do not necessarily need both. Work out which embedding relationships your application actually relies on before you close them.
The nosniff check reports a missing X-Content-Type-Options or a value other than nosniff. Worth fixing, but also worth checking your response content types, because a header cannot repair content served with the wrong type.
Cookie findings
| Finding | What to check |
|---|---|
Missing Secure | Whether this cookie should ever travel over plain HTTP |
Missing HttpOnly | Whether browser scripts genuinely need to read it |
Missing SameSite | Your intended cross-site behavior, including sign-in and embeds |
SameSite=None without Secure | The combination is invalid. Cross-site requires secure transport |
Invalid __Secure- prefix | Whether the cookie meets the prefix’s requirements |
Invalid __Host- prefix | Secure, path, and domain scope requirements of the host prefix |
Partitioned without Secure | A partitioned cookie needs its secure attribute |
Unparseable Set-Cookie | The syntax of the returned header |
Context matters here more than anywhere else on this page. Some cookies deliberately need JavaScript access. Session cookies and preference cookies have genuinely different requirements.
And remember the scan only sees cookies on the responses it collected. Cookies your app sets during sign-in are never assessed.
Other policy findings
Also recognized, as informational findings in the current model: Referrer-Policy set to unsafe-url or an invalid value, an empty or invalid Permissions-Policy, and invalid Cross-Origin-Resource-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Opener-Policy values.
Do not max these out across the board. Cross-origin and permissions controls affect embedding, media, authentication, and third-party resources, and breaking a payment iframe to clear an informational finding is a bad trade.
Verify changes
Apply the policy where the public response is produced, then retest and read back the observed headers. Exercise the important flows yourself, especially sign-in and embedded content, because SSLBoard samples responses rather than auditing every route and authenticated session.
See HSTS for HTTPS persistence, and result states when no header evidence came back at all. For browser semantics, the CSP reference and Set-Cookie reference are the ones to keep open.