Security headers: the October 2026 numbers

The October 2026 security header refresh gives us a current snapshot of the same population. It does not establish a trend: the supplied aggregate contains no earlier figures, so we cannot say which findings improved or worsened. The useful question is what these observations tell a business owner to check next.

Security response headers tell a browser how to handle a website. They can restrict scripts, discourage insecure connections, prevent certain framing behavior and limit information shared with other sites. They generally require no paid product, but safe deployment takes more than copying a configuration line. A restrictive setting can also break a legitimate payment flow, embedded document or customer portal.

The October snapshot

Our aggregate, generated on 2026-10-16 from monthly refresh 20261016, covers the population labelled US B2B SaaS 5-50, with sample size N = 1120. These are the recorded header findings:

• Content-Security-Policy: 72.3% of the US B2B SaaS 5-50 population, N = 1120 (n=810).
• Strict-Transport-Security: 17.6% of the US B2B SaaS 5-50 population, N = 1120 (n=197).
• X-Frame-Options: 60.4% of the US B2B SaaS 5-50 population, N = 1120 (n=677).
• Referrer-Policy: 71.5% of the US B2B SaaS 5-50 population, N = 1120 (n=801).
• Permissions-Policy: 82.3% of the US B2B SaaS 5-50 population, N = 1120 (n=922).
• X-Content-Type-Options: 56.9% of the US B2B SaaS 5-50 population, N = 1120 (n=637).

Methodology: This research uses passive, public-data-only observations of the US B2B SaaS 5-50 population, N = 1120. Results are k-anonymised, and no company is named. The supplied aggregate identifies header findings but does not specify whether each category means missing, present or incorrectly configured. We therefore report the categories without relabelling them as absence rates. Public HTTP observations are not proof of abuse or compromise, and they do not reveal the security of a company's backend.

That distinction matters. Finding a header name in a response does not establish that its value provides useful protection. Equally, a framing protection may be supplied through Content-Security-Policy even when X-Frame-Options is absent. These observations are a starting point for reviewing the actual configuration.

What the settings protect

Content-Security-Policy, often shortened to CSP, can restrict where scripts and other resources load from. A carefully designed policy can reduce exposure to script injection. A permissive policy may offer much less protection, and CSP does not replace fixing the underlying application flaw.

Strict-Transport-Security, or HSTS, tells a browser to use HTTPS for subsequent connections within the policy's scope. It helps prevent insecure HTTP connections after the browser has learned the policy. It does not automatically protect an initial visit before that policy is known.

X-Frame-Options controls whether another page can frame yours, helping address clickjacking. CSP's frame-ancestors directive provides another way to control framing. X-Content-Type-Options tells browsers to respect declared content types rather than guessing in supported contexts, reducing certain MIME sniffing risks.

Referrer-Policy controls how much referring URL information accompanies requests. Permissions-Policy restricts access to supported browser capabilities, such as camera or microphone access. Neither setting replaces access controls or careful handling of client information.

Where to start

Consider a hypothetical accounting practice whose website embeds a scheduling service and links clients to a separate document portal. Copying a strict CSP from another site could disable scheduling while leaving the portal untouched. The right change starts with understanding which systems serve each response.

• Check the sites clients actually use. Review the public website, login page and client portal separately. Use the free public checker as a starting point, then have the responsible provider inspect the returned values and their scope.
• Assign an owner for each configuration. Ask whether headers are controlled by the application, hosting platform or content delivery network. Record who can make and reverse a change. An External Security Posture Assessment can help organise passive external findings for that review.
• Test restrictions against legitimate workflows. For CSP, use report-only testing where appropriate before enforcement. Check scheduling, payments, document previews and authentication. Reporting needs an explicitly configured destination and review process.
• Deploy and inspect again. Confirm that the intended values appear on relevant responses, including redirects and error pages. Test HTTPS readiness before expanding HSTS scope. Keep a rollback path for settings that disrupt client access.

Give your website provider a concrete request: show the current header values, explain what each permits, and demonstrate that the proposed changes preserve your client workflows.