How Security Headers Address the OWASP Top 10

What is the OWASP Top 10#

OWASP, the Open Web Application Security Project, publishes the Top 10 as a consensus list of the most critical web application security risks, updated roughly every 3 to 4 years. The current edition is 2021. The list covers everything from broken access control and cryptographic failures to insecure design and server-side request forgery. It is not a compliance checklist but a framework for understanding where web applications most commonly fail.

The honest premise of this article: HTTP response headers directly address 4 of the 10 categories. A02 (Cryptographic Failures), A03 (Injection), A05 (Security Misconfiguration), and A07 (Identification and Authentication Failures) all have meaningful header-level controls. The other 6 require server-side logic, architecture decisions, or tooling that operates well beyond what a browser instruction can accomplish.

A02: Cryptographic Failures#

A02 covers situations where sensitive data is exposed because encryption is absent, weak, or bypassed. Two response headers contribute directly to this risk category.

Strict-Transport-Security (HSTS) tells browsers to connect only over HTTPS for a specified period and prevents SSL stripping attacks, where an attacker downgrades a connection to plain HTTP before it reaches your server. When preloaded into browser vendor lists, HSTS applies before the very first request, closing the window that even a first-visit HTTP connection would otherwise create. You can read a full explanation of how HSTS works in the HSTS guide.

Upgrade-Insecure-Requests: 1 instructs the browser to upgrade mixed content HTTP requests to HTTPS before sending them. If your page references an image or script over HTTP, this header tells the browser to try the HTTPS version instead. It does not replace HSTS but reduces the window for mixed content warnings on pages that still contain HTTP references.

• Strict-Transport-Security. Enforces HTTPS connections and prevents SSL stripping. Use max-age=31536000; includeSubDomains; preload for the strongest posture.
• Upgrade-Insecure-Requests. Instructs the browser to upgrade HTTP resource requests to HTTPS. A useful complement to HSTS, not a replacement.

A03: Injection#

A03 covers injection broadly, and XSS (Cross-Site Scripting) is the injection variant that browsers can meaningfully help contain. An attacker who finds an XSS vulnerability can inject script into your page. If the browser has no instruction about which scripts are permitted, it will execute anything present. Content Security Policy is an allowlist that tells the browser which scripts, styles, and resources it is permitted to load and execute. A page with a strong CSP can significantly limit the blast radius of an injected script even if the injection itself slips through server-side defences.

X-Content-Type-Options: nosniff prevents browsers from MIME-sniffing a response away from the declared content type. Without it, a browser might interpret a file labeled as plain text as executable JavaScript, opening a path for content-injection attacks. Setting nosniff closes that path.

X-XSS-Protection is now deprecated and disabled in modern browsers. CSP supersedes it entirely. It is worth noting as a legacy header that scan tools still report, but you should not rely on it and should not use it as a substitute for a proper Content Security Policy. If you want to understand how to write a CSP that genuinely reduces injection risk, the guide on removing unsafe-inline from CSP is a practical starting point.

• Content-Security-Policy. Allowlist for scripts, styles, and resources. Limits what an injected script can execute or exfiltrate.
• X-Content-Type-Options: nosniff. Prevents MIME-sniffing. Blocks a class of content injection attacks where files are reinterpreted as executable types.
• X-XSS-Protection. Deprecated. Disabled in modern browsers. CSP supersedes it and provides substantially stronger protection.

A05: Security Misconfiguration#

A05 is the largest category and the one where most HTTP security headers live. The key insight is that misconfiguration does not always mean a wrong value. Sometimes it means no value, leaving the browser to its permissive default. Most browsers will happily embed your page in a frame, send the full referring URL to other origins, and grant access to the camera if asked, unless you instruct them otherwise. Headers are how you issue those instructions.

X-Frame-Options prevents clickjacking by controlling whether a page can be embedded in a frame or iframe on another origin. Setting it to DENY or SAMEORIGIN removes an entire class of UI-redress attacks.

Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, and Cross-Origin-Resource-Policy together establish cross-origin isolation. COOP prevents other browsing contexts from retaining a reference to your window. COEP requires that all resources your page loads have opted into cross-origin sharing. CORP controls which origins can load your resources. Together they protect against Spectre-style side-channel attacks and tighten control over what cross-origin contexts can interact with your document.

Referrer-Policy limits how much of the current URL is included in the Referer header sent to other origins. Without it, navigating from a private dashboard to an external link can leak the full path of the page the user was on.

Permissions-Policy restricts which browser features a page or embedded frame can access. You can disable geolocation, camera, and microphone access entirely, or scope them to specific origins. Features not listed remain at browser default.

X-Permitted-Cross-Domain-Policies, X-DNS-Prefetch-Control, and Origin-Agent-Cluster are lower-profile headers that each remove a specific misconfiguration by design. X-Permitted-Cross-Domain-Policies controls cross-domain policy file access for legacy plugins like Flash. X-DNS-Prefetch-Control manages whether the browser pre-resolves DNS for links on a page, which can leak browsing intent. Origin-Agent-Cluster requests that the page run in its own isolated agent cluster, strengthening process separation.

• X-Frame-Options. Prevents clickjacking by blocking your page from being embedded in frames on other origins.
• Cross-Origin-Opener-Policy. Prevents other browsing contexts from holding a reference to your window after navigation.
• Cross-Origin-Embedder-Policy. Requires cross-origin resources to opt into sharing, enabling cross-origin isolation.
• Cross-Origin-Resource-Policy. Controls which origins can load your resources in their pages.
• Referrer-Policy. Limits how much of the current URL is sent as the Referer header to other origins.
• Permissions-Policy. Restricts which browser features (camera, geolocation, microphone) a page or frame can access.
• X-Permitted-Cross-Domain-Policies. Controls cross-domain policy file access for legacy plugin contexts.
• X-DNS-Prefetch-Control. Manages DNS prefetching behavior to reduce information leakage.
• Origin-Agent-Cluster. Requests isolated agent cluster execution for stronger process separation.

If you want to verify that your site is actually setting all of these, the guide on how to check security headers walks through the fastest ways to do it.

A07: Identification and Authentication Failures#

A07 covers failures in identity management and session handling. The header-level contribution here is narrow but real.

Clear-Site-Data instructs the browser to wipe cookies, local storage, session storage, and cached responses for the origin when included in a server response. The most common use case is logout: sending this header in your logout response ensures that session tokens and cached credentials are removed from the browser immediately rather than persisting after the user signs out. Without it, a session token stored in a cookie or local storage can remain accessible long after the user believes they have logged off, particularly on shared or borrowed devices.

This is a short section because the mapping is genuinely narrow. The bulk of A07 is addressed by server-side session management, secure credential storage, rate limiting, and multi-factor authentication, none of which a response header can substitute for.

• Clear-Site-Data. Sent on logout to wipe cookies, storage, and cache for the origin. Prevents session token persistence after sign-out.

What headers don't cover#

The remaining 6 categories in the OWASP Top 10 are not meaningfully addressed by HTTP response headers. Response headers are a browser-level control. They describe how the browser should handle content. They cannot fix logic errors in your application, patch outdated libraries, or detect attacks in progress.

• A01: Broken Access Control. Access control decisions happen on the server. A header cannot enforce who is allowed to read a record or perform an action.
• A04: Insecure Design. Architectural risks require design changes. No header can compensate for a fundamentally flawed threat model.
• A06: Vulnerable and Outdated Components. Dependency scanning, patch management, and software bills of materials are the controls here. One partial exception: Subresource Integrity (SRI) attributes on script and link tags can verify the integrity of third-party resources loaded from CDNs, which overlaps slightly with this category.
• A08: Software and Data Integrity Failures. Verification of build pipelines, signed packages, and CI/CD integrity are outside browser scope entirely.
• A09: Security Logging and Monitoring. Logging and alerting happen on the server and in your observability stack. No header configures that.
• A10: Server-Side Request Forgery. SSRF is a server-side vulnerability. The server makes the outbound request; the browser is not involved.

For a fuller picture of how headers fit alongside other defences, the guide on the 6 layers of website security places them in context with access control, TLS, monitoring, and application-layer controls.

FAQ#