HTTP Security Headers Explained: Complete Guide

Security headers are a simple but highly effective layer of website defence. This guide covers every major header, what attack it mitigates, and how to check your current score.


HTTP security headers are response headers your web server sends with every page. They instruct the browser how to behave when handling your content — restricting which resources can be loaded, how your site can be framed, and what browser features are permitted. Correctly configured, they neutralise entire classes of attack without changing a single line of application code.

Why Security Headers Matter

Application firewalls and HTTPS encryption protect the transport layer, but they do nothing to prevent the browser from executing injected scripts, loading your site inside a malicious iframe, or leaking sensitive URLs to third-party analytics. Security headers close these browser-level gaps and are increasingly factored into automated security assessments and compliance audits.

Adding the headers costs almost nothing — typically a few lines in your server configuration — yet the protection they provide is significant. Organisations that score poorly on security header audits are considered lower-hanging fruit for automated scanners and targeted attacks.

Check Your Headers NowUse the ShowDNS Security Headers Scanner to see which headers your site is currently missing and get a grade. The scan takes under ten seconds and shows the exact header values returned.

The Major Security Headers at a Glance

HeaderPrimary PurposeAttack Mitigated
Strict-Transport-SecurityForce HTTPS connectionsProtocol downgrade, SSL stripping
Content-Security-PolicyRestrict resource loading originsXSS, data injection, clickjacking
X-Frame-OptionsControl iframe embeddingClickjacking
X-Content-Type-OptionsPrevent MIME type sniffingMIME confusion attacks
Referrer-PolicyControl Referer header contentInformation leakage
Permissions-PolicyRestrict browser feature accessFeature abuse, privacy violations
Cross-Origin-Opener-PolicyIsolate browsing contextCross-origin attacks, Spectre
Cross-Origin-Embedder-PolicyRequire CORS for embedded resourcesCross-origin data leaks

Strict-Transport-Security (HSTS)

HSTS tells browsers to only connect to your site over HTTPS, even if the user typeshttp:// or follows an HTTP link. The browser caches the policy for the duration set in max-age and refuses plain HTTP connections for that period without contacting the server first.

http
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

The includeSubDomains flag extends the rule to all subdomains. The preload flag signals eligibility for the browser preload list, which enforces HTTPS even before the first visit. Learn more in the HSTS header guide.

Content-Security-Policy (CSP)

CSP is the most powerful security header. It gives you fine-grained control over every category of resource the browser is allowed to load. By allowlisting only the origins you trust, you prevent injected scripts from running and stop attackers from exfiltrating data to rogue servers.

http
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'

CSP is complex to configure without breaking functionality. Start withContent-Security-Policy-Report-Only mode, review violation reports, and tighten the policy progressively. See the full CSP explainer for details.

X-Frame-Options

This header prevents your page from being embedded in a frame or iframe on another domain, blocking clickjacking attacks. DENY forbids all framing; SAMEORIGIN allows framing only by pages on the same origin.

http
X-Frame-Options: DENY

Note that frame-ancestors in CSP provides more granular control and is the modern replacement. Keep X-Frame-Options for legacy browser compatibility.

X-Content-Type-Options

The only valid value for this header is nosniff. It prevents browsers from "sniffing" the MIME type of a response and treating it differently from the declaredContent-Type. Without this header, a browser might execute a JavaScript file served with a misleading content type.

http
X-Content-Type-Options: nosniff

Referrer-Policy

When a user follows a link from your site to another, the browser sends a Refererheader containing the originating URL. Without a policy, full URLs including query strings can be leaked to third parties, potentially exposing user IDs, session tokens, or sensitive path segments.

http
Referrer-Policy: strict-origin-when-cross-origin

The recommended value strict-origin-when-cross-origin sends only the origin (no path or query) on cross-origin requests and sends the full URL only for same-origin navigation.

Permissions-Policy

Formerly known as Feature-Policy, this header controls which browser features and APIs your site (and any embedded third-party iframes) are allowed to use. Disabling features like geolocation, microphone, and camera by default reduces the attack surface of embedded content and third-party scripts.

http
Permissions-Policy: geolocation=(), microphone=(), camera=()

Cross-Origin-Opener-Policy (COOP)

COOP allows you to isolate your browsing context from other origins. When set tosame-origin, popups opened by your page cannot communicate back with it unless they are on the same origin. This prevents cross-origin attacks that exploit thewindow.opener reference and is required to enable certain performance features likeSharedArrayBuffer.

http
Cross-Origin-Opener-Policy: same-origin

Cross-Origin-Embedder-Policy (COEP)

COEP requires that every resource loaded by your page either comes from the same origin or explicitly opts in via CORS or CORP headers. Combined with COOP, it enables cross-origin isolation, which is required for high-resolution timers and Spectre mitigations. Set it torequire-corp once all your third-party resources support the necessary CORS headers.

http
Cross-Origin-Embedder-Policy: require-corp
COOP + COEP Can Break Third-Party IntegrationsEnabling cross-origin isolation (COOP: same-origin + COEP: require-corp) requires that every external resource your page loads — CDN assets, analytics, ad networks — also sets the appropriate CORP or CORS headers. Audit all embedded content carefully before deploying these two headers in combination.

How to Check Your Security Header Score

Several tools grade websites against their security header implementation:

  • ShowDNS Security Headers Scanner — scans your domain and lists every present and missing security header with recommended values.
  • ShowDNS HTTP Header Checker — inspect the raw response headers returned by any URL.
  • securityheaders.com — assigns letter grades from F to A+ and provides remediation advice for each missing header.

An A+ score typically requires HSTS with a long max-age, a robust CSP, X-Frame-Options, nosniff, Referrer-Policy, and Permissions-Policy all correctly configured.

Frequently Asked Questions

Do security headers affect website performance?

Negligibly. Security headers add a few bytes to HTTP responses but have no meaningful impact on load times. HSTS can actually improve performance by eliminating HTTP-to-HTTPS redirect round-trips for returning visitors.

Which headers should I add first?

Start with the low-risk, high-reward headers: X-Content-Type-Options: nosniff,X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, and Strict-Transport-Security with a short max-age. Add CSP last because it requires the most careful configuration.

Can I set security headers without server access?

Many CDNs (Cloudflare, Fastly, Vercel, Netlify) allow header injection via dashboard settings or configuration files, without requiring direct server access. Check your CDN or hosting provider's documentation for header configuration options.

Do security headers work with single-page applications?

Yes. Security headers are set at the HTTP response level, so they apply regardless of whether the page is server-rendered or a client-side SPA. For SPAs, you may need to adjustconnect-src and script-src in your CSP to allow API calls and dynamically loaded modules.

Related Articles