Skip to content
Browse tools
HomeKnowledge Base Security Headers HTTP Security Headers Explained
Security Headers

HTTP Security Headers Explained

What Strict-Transport-Security, Content-Security-Policy, X-Frame-Options and the other headers on the Website Inspector's Security Header Review actually protect against.

These are the response headers the Website Inspector's "Security Header Review" card checks for any URL you give it — real headers read directly from the response, not a simulated check. Each one below explains what it does and why it is worth adding.

Strict-Transport-Security (HSTS)

Strict-Transport-Security tells the browser to only ever connect to this domain over HTTPS for a set period of time (via max-age), even if the user types http:// or clicks an old http:// link. Once a browser has seen this header once, it will not attempt a plain HTTP connection again until the max-age expires.

This closes a real attack window: without HSTS, that first HTTP request before a redirect to HTTPS can be intercepted and altered by an attacker on the same network — a classic public Wi-Fi risk. A typical value is max-age=31536000; includeSubDomains.

Content-Security-Policy (CSP)

Content-Security-Policy is an allowlist telling the browser exactly which sources of scripts, styles, images, fonts and other resources are allowed to load on a page. It is one of the strongest defenses against cross-site scripting (XSS), because even if an attacker manages to inject a <script> tag, the browser will refuse to execute it unless it comes from an allowed source.

Directives like unsafe-inline and unsafe-eval weaken this protection significantly by allowing inline and dynamically-generated scripts to run — a strict policy uses nonces or hashes instead when inline scripts are unavoidable.

X-Frame-Options

X-Frame-Options controls whether a page can be rendered inside an <iframe> on another site. Setting it to DENY or SAMEORIGIN prevents clickjacking — an attack where a malicious site frames your page invisibly and tricks a user into clicking a button on your page while believing they are interacting with the attacker's page.

The modern, more flexible equivalent is the CSP frame-ancestors directive, which supports listing multiple allowed origins; many sites set both for broader browser support.

X-Content-Type-Options

Setting X-Content-Type-Options: nosniff stops the browser from trying to guess ("sniff") a file's type by inspecting its content instead of trusting the server's declared Content-Type. Without it, a browser might, for example, interpret a file served as text/plain as HTML or JavaScript if its contents look like that — turning an innocuous file upload into a script-execution vector.

Referrer-Policy

Referrer-Policy controls how much of the current page's URL gets sent in the Referer header when a user clicks a link to another site, or when a resource like an image loads from another domain. URLs can contain sensitive information — session identifiers, search queries, internal paths — that you may not want leaking to third parties.

A common, privacy-conscious value is strict-origin-when-cross-origin, which sends the full URL to same-origin requests but only the origin (no path or query string) when the request crosses to a different site.

Permissions-Policy

Permissions-Policy (formerly Feature-Policy) lets a page explicitly enable or disable access to specific browser features and APIs — camera, microphone, geolocation, USB, fullscreen and more — for itself and for anything embedded in it via <iframe>.

Explicitly disabling features a page does not use (for example camera=(), microphone=(), geolocation=()) reduces the impact if a third-party script or embedded frame is ever compromised, since the browser refuses the API call outright regardless of what the script asks for.

Cross-Origin-Opener-Policy (COOP)

Cross-Origin-Opener-Policy isolates a page's browsing context from windows opened by other origins — for example, a page opened via window.open() from a different site can no longer hold a direct JavaScript reference back to your page's window object. Setting it to same-origin is what allows a browser to grant a page access to powerful APIs that require full process isolation, such as SharedArrayBuffer.

Cross-Origin-Resource-Policy (CORP)

Cross-Origin-Resource-Policy lets a server declare whether a specific resource — an image, script, font, JSON response — is allowed to be loaded by pages on other origins. Setting it to same-origin or same-site blocks other sites from embedding that resource directly, which helps prevent certain cross-origin information-leak attacks, such as inferring private data through image-loading side effects.

Cross-Origin-Embedder-Policy (COEP)

Cross-Origin-Embedder-Policy requires that every cross-origin resource a page loads — images, scripts, iframes — has explicitly opted in via CORS or CORP before the browser will load it. Combined with COOP, it puts a page into "cross-origin isolation," a stricter security state required to safely use powerful features like SharedArrayBuffer and high-resolution timers.

Frequently Asked Questions

Which security header should I add first if I can only add one?

Content-Security-Policy generally has the largest impact, since it directly blocks a wide range of script-injection attacks, but Strict-Transport-Security is also a very high-value, low-effort addition.

Will these headers break my site if I add them?

A strict Content-Security-Policy can block inline scripts, third-party widgets or fonts you did not account for, so it is worth testing with a report-only policy before enforcing it. Most of the other headers are safe to add with no testing.

What does it mean if a header shows Pass with a warning?

It means the header is present but its configured value is weaker than recommended - for example a Content-Security-Policy that still allows unsafe-inline scripts.

Are these headers a complete security solution?

No. They reduce specific classes of client-side attacks like XSS and clickjacking, but they do not replace input validation, authentication, dependency updates or other server-side security practices.