Security Headers Check: What StackShield Inspects

What this check looks for

StackShield requests your pages and reads the response headers, the same set a browser receives on every visit. It checks for the presence and configuration of the headers that instruct the browser how to treat your site: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy and Permissions-Policy.

These are not visible on the page. They are directives sent alongside every response, and their absence is silent.

Why it matters

Security headers are the browser-side half of your defences. HSTS forces every future connection over HTTPS, closing the window where a first request over HTTP can be intercepted. A Content Security Policy limits which scripts can run, which is often the difference between a reflected XSS payload doing nothing and executing in your users' sessions. X-Frame-Options stops your pages being framed for clickjacking.

None of these headers fix a vulnerability in your code. They reduce what an attacker can do with one, and several of them are checked by compliance frameworks and by the security questionnaires enterprise customers send.

What a failed check means

A failed check means one or more of these headers is absent or set to a permissive value. It is rarely an emergency on its own, and it is one of the most common findings on any application, which is exactly why it is worth clearing: it is cheap, it is visible to anyone who inspects your responses, and a missing CSP leaves you without the mitigation that turns a serious XSS bug into a survivable one.

Headers are set once in middleware and apply site-wide.

See the step-by-step remediation: how to fix this.