HTTP Security Headers Explained: Which Ones Protect and Which Are Merely Present

HTTP security headers give the browser rules for a response. Protection depends on the values, interactions between policies and browser support. A list of present header names is not enough.

CSP limits scripts and other resources. HSTS requires HTTPS for known hosts. X-Frame-Options or CSP frame-ancestors limits framing. Referrer-Policy controls information about a request’s origin. Permissions-Policy restricts supported browser features; disabling a camera or geolocation can certainly break required functionality.

CSP: An exception does not cancel everything

Content-Security-Policy complements safe output handling and input processing as an additional defence against cross-site scripting (XSS). In an XSS attack, injected code runs in the browser as part of the affected page. CSP does not replace fixing application defects. The directive matters: script-src covers scripts, img-src covers images, and default-src provides a fallback for many resource directives.

With default-src 'self' 'unsafe-inline', inline scripts are allowed unless a more specific script directive applies. External resources remain generally restricted to the same origin. The policy is weakened, but not entirely ineffective. An 'unsafe-inline' value only in style-src does not automatically allow inline scripts.

'unsafe-eval' allows certain evaluations of strings as code, which differs from allowing inline scripts. Nor does default-src * automatically allow inline scripts or eval. A more specific directive such as script-src-elem can change the assessment again.

Nonces and hashes in the relevant directive

A cryptographically random nonce, newly generated for each response, can identify permitted scripts. The value must appear both in the relevant CSP source expression and on the script element. A hash is a value calculated from the script content. It allows exactly matching script content; even whitespace changes can require a new hash.

In the source list governing the script, a nonce or hash overrides the blanket inline allowance in supporting browsers. A nonce in a different directive is insufficient. Reusing a static nonce is unsuitable; cached HTML can instead use hashes or consistent regeneration of both the header and HTML.

Nonces do not cover event attributes such as onclick. Hashes additionally require 'unsafe-hashes' for such attributes; moving event handling into scripts is usually easier to secure. Content-Security-Policy-Report-Only supports testing and reports violations but does not block according to that policy.

HSTS: Lifetime, HTTPS and domain coverage

max-age specifies the storage period in seconds. A valid HSTS response over error-free HTTPS refreshes the expiry. While the policy applies, the browser upgrades HTTP requests for the covered host to HTTPS. HSTS headers received over unencrypted HTTP are ignored.

max-age=300 protects for five minutes and can be useful during a controlled rollout. Longer periods are usual for permanent HTTPS deployments. includeSubDomains requires reliable HTTPS on every affected subdomain, including internal systems.

The preload keyword alone does not add a domain to browser lists. Inclusion requires a separate process, compliance with the list’s requirements and distribution to browsers. The official preload site currently recommends HSTS but no longer recommends preloading generally. Removing the keyword does not immediately reverse an existing listing.

Framing: Only an enforced policy takes precedence

X-Frame-Options: DENY prevents framing, while SAMEORIGIN limits framing to the same origin. In supporting browsers, frame-ancestors in an enforced CSP takes precedence over X-Frame-Options. A Report-Only header does not override X-Frame-Options.

frame-ancestors * broadly permits ordinary HTTP(S) origins; an accompanying DENY does not rescue that configuration. Multiple enforced CSPs apply together. To prohibit framing, a consistent pairing is frame-ancestors 'none' with X-Frame-Options: DENY as a compatibility fallback.

Referrer: An origin is more than a domain

strict-origin-when-cross-origin generally sends the address, including path and query parameters, within the same origin. Across origins, normally only the scheme, host and applicable port remain; moving from HTTPS to insecure HTTP suppresses the referrer. Different subdomains or ports already constitute different origins.

unsafe-url can expose paths and query parameters to other origins, including over HTTP. URL fragments after # and credentials are not included in the referrer. no-referrer suppresses the referrer. Link-level rules, browser preferences or extensions can affect the actual output. Sensitive data should preferably stay out of URLs.

A snapshot cannot replace a browser test

The HTTP security header checker fetches a public address with a limited number of HTTP redirects and evaluates the final response using simplified rules. The assessment is not a complete browser model: repeated headers, nonces, more specific CSP directives and Report-Only combinations need additional verification.

The relevant evidence consists of actual responses for important pages, error pages and authentication states, together with observed browser behaviour. Redirects require multiple requests. JavaScript navigations, meta policies and necessary application features are not fully tested by a header snapshot.