HTTP Security Headers Benchmarks 2026: Adoption Data and Setup Guide

HTTPS is nearly universal. Good security headers aren’t.

The latest large-scale crawl from the 2025 HTTP Archive Web Almanac found that no individual security header appeared on even half of mobile sites. X-Content-Type-Options, the most common, reached 48.96%. Content Security Policy appeared on 21.90%. Permissions Policy appeared on just 3.72%.

That gap matters because TLS and response headers solve different problems. HTTPS protects data while it travels between a visitor and a server. Headers tell the browser what content may run, whether another site may frame the page, when HTTPS is mandatory, and which browser features a document may use.

This resource turns the current adoption data into a working plan. Web professionals can use it to benchmark builds, explain priorities to clients, and avoid copying a header bundle that breaks checkout, analytics, maps, or embedded forms.

HTTP security header adoption benchmarks

The table below uses the HTTP Archive’s July 2025 mobile dataset. The study’s public methodology is based on millions of URLs from the Chrome User Experience Report, and its queries are published for reproduction. Percentages come from the chapter’s security-header dataset.

Adoption is moving upward. From 2024 to 2025, HSTS gained 4.02 percentage points, CSP gained 3.39 points, and X-Content-Type-Options gained 2.30 points, according to the same HTTP Archive analysis. CSP grew from 18.5% to 21.9%, a relative increase of roughly 18%.

Popularity also changes the benchmark. X-Frame-Options appeared on 67% of the top 1,000 mobile sites but only 30% of all sites visited by the browser in the chapter’s popularity comparison. Larger sites tend to have security teams, stricter release processes, and more reasons to defend authenticated applications. Small sites don’t get a pass, though. Several valuable headers are one-line configuration changes.

What each priority header actually does

Raw adoption is not a to-do list. Some uncommon headers are specialized. One common header is obsolete. The right configuration depends on what the site loads and what visitors can do.

1. Content-Security-Policy: control what may execute

A Content Security Policy, or CSP, limits the sources from which a page may load scripts, styles, images, frames, fonts, and other resources. It can reduce the impact of cross-site scripting and data-injection attacks. MDN’s CSP guide describes it as a browser-enforced allowlist delivered through the Content-Security-Policy response header.

This is the highest-value header that also creates the most implementation work. A policy such as default-src 'self' will break many ordinary business sites because they load Google Analytics, YouTube, payment widgets, chat tools, map embeds, web fonts, or form scripts from outside domains.

Start with Content-Security-Policy-Report-Only. That mode reports violations without blocking resources, which lets the team collect real browser behavior before enforcement. The OWASP Secure Headers Project recommends testing policies carefully and provides current examples.

Avoid making 'unsafe-inline' and broad wildcards permanent fixes. They may stop visible breakage while weakening the policy’s protection. For scripts that must run inline, CSP supports nonces and hashes. MDN’s strict CSP guidance explains how those approaches work.

2. Strict-Transport-Security: make HTTPS mandatory

HSTS tells browsers to use HTTPS for future requests to a domain. This closes the window in which a person types a bare domain, the browser first requests HTTP, and the server redirects to HTTPS. The browser only honors HSTS when it receives the header over a secure connection, as specified in MDN’s HSTS reference.

A common starting value is:

Strict-Transport-Security: max-age=31536000

Add includeSubDomains only after every subdomain works over HTTPS. Add preload only after reading the HSTS preload requirements and accepting that removal is slow. A forgotten vendor portal, legacy mail host, or development subdomain can become unreachable if the parent policy covers it before TLS is ready.

The 2025 crawl found that 96% of observed HSTS headers contained a valid max-age, while use of includeSubDomains and preload each rose by about four percentage points, according to the Web Almanac’s HSTS findings.

3. X-Content-Type-Options: stop MIME guessing

X-Content-Type-Options: nosniff tells browsers to respect declared content types instead of guessing that a response might be executable CSS or JavaScript. MDN documents the single valid directive, nosniff, and how browsers apply it to script and style destinations.

This is a sensible default, but it can expose an existing server mistake. If a JavaScript file is served as text/plain, turning on nosniff may cause the browser to reject it. Fix the incorrect Content-Type; don’t remove the protection to hide the error.

4. Referrer-Policy: limit data sent on outbound requests

The Referer request header can reveal the page a visitor came from. That may be useful for analytics, but full URLs can contain paths or query strings a third party should not receive. Referrer-Policy controls how much referral information the browser shares.

Modern browsers use strict-origin-when-cross-origin as the default, according to MDN’s Referrer-Policy reference. Setting it explicitly makes the site’s intent clear and protects behavior in environments with different defaults. Privacy-sensitive applications may choose no-referrer; marketing sites often prefer strict-origin-when-cross-origin because same-site analytics retain the full path while cross-site requests receive only the origin.

5. Frame protection: CSP first, X-Frame-Options for coverage

Clickjacking places a real page inside a deceptive frame and tricks someone into clicking controls they cannot properly see. CSP’s frame-ancestors directive controls which parents may embed a page. MDN recommends frame-ancestors for flexible framing rules.

X-Frame-Options: DENY blocks all framing, while SAMEORIGIN permits framing by pages from the same origin. The old ALLOW-FROM directive is obsolete and modern browsers ignore it, according to MDN’s X-Frame-Options reference.

If partners legitimately embed a scheduler, dashboard, or white-label page, test that flow before using DENY. For a public brochure site with no framing requirement, frame-ancestors 'none' plus X-Frame-Options: DENY is a defensible baseline.

6. Permissions-Policy: shut off browser features you do not use

Permissions Policy can restrict access to features such as the camera, microphone, and geolocation for the main page and embedded frames. The web platform’s Permissions Policy documentation explains that the header and an iframe’s allow attribute work together.

A site that never needs sensitive device features might begin with:

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

The 3.72% adoption rate looks low, but it grew by almost 60% relative to 2024, according to the HTTP Archive analysis. Don’t paste a long list from an old generator. Feature names and browser support change, and an empty allowlist can break a video consultation or location finder.

Headers you should not add just to improve a scanner grade

Security scanners are useful, but a higher letter grade is not the same as lower business risk.

X-XSS-Protection still appeared on 23.16% of mobile sites, yet it is deprecated. MDN marks the header non-standard and deprecated, and notes that its behavior could create vulnerabilities in otherwise safe sites. A tested CSP is the modern control.

Expect-CT is also obsolete. Certificate Transparency enforcement is built into modern browsers, and MDN marks Expect-CT as deprecated. Feature-Policy has been replaced by Permissions-Policy.

The cross-origin isolation family, COOP, COEP, and CORP, can protect advanced applications and enable features that require cross-origin isolation. They are not harmless decoration. MDN’s cross-origin isolation guide shows that isolation depends on coordinated policies and can affect popups and external resources. Add these when the application has a clear requirement and a test plan.

Clear-Site-Data is different. Its 0.01% adoption does not make it useless. It belongs on specific responses, usually logout or account-recovery endpoints, where it can clear cookies, cache, and storage. MDN’s Clear-Site-Data reference explains the available directives. Measuring only home pages naturally understates endpoint-specific use.

A three-tier implementation framework

Use risk and testing effort, not header count, to plan the work.

Tier 1: safe baseline

For a typical brochure or lead-generation site, begin with X-Content-Type-Options: nosniff, an explicit Referrer-Policy, frame protection, and HSTS after confirming HTTPS across the required hostnames. These controls are understandable, easy to verify, and unlikely to disrupt a site when prerequisites are checked.

Tier 2: inventory and observe

Build a list of every external domain used by scripts, fonts, images, frames, forms, analytics, consent tools, chat, maps, video, and payments. Then deploy a report-only CSP. Review violations from real templates and transactions, not just the home page. Move to enforcement after the team has tested forms, checkout, account login, search, embeds, and tag-manager changes.

Add a narrow Permissions Policy based on actual feature use. Record why each exception exists and who owns the vendor that requires it.

Tier 3: application-specific isolation

Authenticated applications, sites processing sensitive data, and software using SharedArrayBuffer or powerful browser APIs may need COOP, COEP, CORP, endpoint-specific Clear-Site-Data, and more detailed CSP directives. Treat these as application engineering work. Include browser compatibility, third-party integrations, authentication popups, downloads, and incident recovery in acceptance testing.

Security header audit checklist

Run this check after launches, CDN changes, platform migrations, and major tag updates:

1. Request the final HTTPS URL with curl -I https://example.com/ and record the headers after redirects.
2. Test representative page types, including forms, checkout, login, search, embedded media, and error pages. A home-page pass does not prove site-wide coverage.
3. Scan the public site with the free MDN HTTP Observatory, which has analyzed more than 6.9 million sites through 47 million scans.
4. Confirm that HSTS scope matches the subdomains that can support HTTPS.
5. Check the browser console for blocked content and CSP violations.
6. Verify that CSP reporting reaches a monitored destination and does not collect sensitive URLs unnecessarily.
7. Test all approved framing, payment, map, chat, consent, analytics, and authentication flows.
8. Remove deprecated headers and document every exception.
9. Assign an owner and review date. A header policy can decay when vendors, tags, and application routes change.

Also test where the header is set. A CDN, reverse proxy, hosting dashboard, framework middleware, and web server can each add or overwrite response headers. Duplicate CSP headers are enforced together, which can create a stricter result than either team intended. MDN explains the effect of multiple CSP policies.

Example baseline configurations

The exact syntax depends on the server. These examples show where a baseline can live, not a universal policy for every site.

For Nginx:

add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header X-Frame-Options "DENY" always;
add_header Strict-Transport-Security "max-age=31536000" always;

For Apache:

Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set X-Frame-Options "DENY"
Header always set Strict-Transport-Security "max-age=31536000"

For a CSP rollout, the first header should normally be observational:

Content-Security-Policy-Report-Only: default-src 'self'; report-to csp-endpoint

Do not deploy these snippets blindly. A site designed to be embedded cannot use DENY. HSTS requires working HTTPS. A real CSP needs the site’s resource inventory and a reporting setup. OWASP’s HTTP Headers Cheat Sheet is a useful technical reference when adapting the baseline.

The benchmark that matters

The web-wide numbers answer, “What do other sites send?” Your own benchmark should answer, “Which browser-enforced protections fit this site’s threats, and do they still work after the next release?”

Start with the low-risk defaults. Inventory dependencies. Roll CSP out in report-only mode. Test revenue paths. Then monitor the policy like any other production control.

If you need a website team that can improve security without breaking the pages that bring in business, talk with YourWebTeam.