Security · Explainer

CSP, secure cookies and HSTS

A valid certificate gets you the padlock. These three headers decide what an attacker can actually do to a visitor once the page is loaded, and all three are set in one place.

Check my headers freeTechnical SEO Checker

HTTPS is the floor, not the ceiling

Encryption protects the connection. It says nothing about what the page is allowed to load or what happens to your cookies.

A correctly configured certificate means nobody can read the traffic between browser and server. It does not stop the page loading a script from a compromised third-party CDN, and it does not stop a session cookie being read by injected JavaScript. Those are separate problems with separate headers, and unlike the certificate they produce no visible warning when missing. A site can score perfectly on certificate checks and still have all three of these absent.

What each header is for

Three narrow jobs. None overlaps with the others.

Content-Security-Policy

Declares which sources the page may load scripts, styles, images and frames from. Anything outside the allowlist is blocked, which turns a third-party compromise from a full takeover into a blocked request.

Start in report-only mode. A policy written blind will break something, and report-only tells you exactly what before any visitor is affected.

Secure, HttpOnly and SameSite on cookies

Secure stops the cookie being sent over http. HttpOnly hides it from JavaScript, so injected script cannot steal a session. SameSite limits when it is sent cross-site, which blunts cross-site request forgery.

Session cookies need all three. The common failure is a framework default that sets none of them, carried unnoticed into production.

Strict-Transport-Security

Tells the browser to use https for this domain for a stated period, even if a link or typed address says http. It closes the window a redirect leaves open on that very first request.

Without it, the initial http request still happens before your 301 answers, and that request is interceptable.

upgrade-insecure-requests

A CSP directive that rewrites http asset references to https automatically. It is a useful net for content you cannot easily edit.

It is not a repair. It does nothing when the asset has no https version, and the wrong URLs stay in your content: see mixed content.

A sensible order to adopt them

Risk of breakage runs low to high, so do them in that order.

Cookie flags first: adding Secure, HttpOnly and SameSite to session cookies is a configuration change with almost no chance of breaking a normal site, and it removes the most directly exploitable weakness. HSTS next, starting with a short max-age so a mistake expires quickly rather than pinning visitors to a broken configuration for a year. CSP last and in report-only mode, because it is the only one that can blank a page if written wrong, and the report tells you what a live policy would have blocked. Preload lists are a separate decision: entry is easy and removal is slow, so treat it as a commitment rather than a checkbox.

Why this belongs in a technical audit

Headers are set per response, so they drift per section.

Headers are usually configured at the server or proxy, which means different sections of a site can end up with different sets. An app behind one proxy gets the full list while a marketing subdirectory served from somewhere else gets none. Checking the homepage tells you about the homepage and nothing more, and the section that handles logins is often the one configured separately.

A crawl that records response headers per page finds the inconsistency directly. That is usually the real finding: not that a site has no security headers, but that the half of it nobody remembered is missing them.

What the audit actually looks for

Each check is narrower than the header itself, which is worth knowing before you read a clean result as more than it says.

The HSTS check confirms the header is present and that it isn't disabled with max-age=0. It doesn't require preload or includeSubDomains to pass, those are worth adding but are extra credit, not the floor. The cookie check reads every Set-Cookie header on the crawl and flags any cookie missing Secure, HttpOnly or SameSite, naming which flag is absent. A CSP that's present at all satisfies the audit's own check for it; the content of the policy, what it actually allows, is a judgment call for you to make when you write it, not something a crawler can grade.

CSP, cookies and HSTS questions, answered

Does HSTS need preload to work?

No. A plain HSTS header protects every visit after the browser has seen it once. preload closes the one remaining gap, the very first request ever made to your domain, by shipping the instruction inside the browser itself. It's a meaningful extra step, not a requirement for HSTS to do its main job.

What's the risk of the HSTS preload list?

Entry is close to permanent in practice: removal is slow and has to propagate through browser updates. A domain that later needs to serve anything over plain http, even briefly, will find every browser refusing the connection. Preload every subdomain covered by includeSubDomains too, or one unready subdomain gets locked out with the rest.

Which SameSite value should a normal session cookie use?

Lax is the sensible default: it blocks the cookie on cross-site subrequests while still sending it when someone arrives via a link from elsewhere. Strict is tighter but can break a login that starts from an external link. None is only for cookies that must work cross-site, and it requires Secure as well.

Why start CSP in report-only mode?

A policy written blind almost always blocks something legitimate: an analytics script, a font host, a payment widget. Content-Security-Policy-Report-Only enforces nothing, it only logs what would have been blocked. Review that log over real traffic, build an accurate allowlist, then switch to the enforcing header.

If my whole site is HTTPS, do I still need CSP?

Yes, they solve different problems. HTTPS protects data in transit. CSP restricts what the loaded page is allowed to run, which is what limits the damage if a third-party script you depend on is ever compromised. A fully HTTPS site with no CSP is still exposed to a hijacked script loading freely from anywhere.

What order should I actually roll these out in?

Cookie flags first, since adding Secure, HttpOnly and SameSite is unlikely to break anything. HSTS next, with a short max-age initially so a mistake expires quickly. CSP last, in report-only mode, since it's the one that can blank a page if written wrong before you've seen what it would have blocked.

See which pages are missing which headers

Free to start. Reports missing CSP and HSTS, and cookies set without Secure, HttpOnly or SameSite, across the whole site.

Start my free audit