CIPHERCUE
We ran 56,251 HTTP header checks across the primary domains of 50,769 companies in CipherCue's tracked entity set, most recently between 2026-03-26 and 2026-08-03. In 47.4% of those observations, the response we captured contained none of the seven security headers in our original test: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Permissions-Policy, Referrer-Policy, and X-XSS-Protection. Because a small number of domains were checked more than once in this window, that is currently an observation-level rate rather than a deduplicated company-level rate. "No security headers" here means none of these seven specific headers appeared on the captured response, not that the response carried no HTTP headers of any kind.
What this measures
This is a presence check on a single captured HTTP response, not a security audit. We recorded whether each header appeared on that response, not whether its value was well-configured, and not what the same site sends on other routes, subdomains, or response types. Response type matters here: a redirect, an API response, an error page, or a bot-block page can legitimately carry a different header set to the final HTML document a visitor actually reads, and our data does not consistently record which type of response was captured for every check. A missing header on one observed response is evidence about that response, not a claim that the header is absent everywhere on the site, and it does not, on its own, demonstrate a working vulnerability.
What the headers do
Six of these headers are current browser-security controls; the seventh, X-XSS-Protection, is deprecated and included in the original measurement for completeness rather than because we treat it as equivalent to the other six.
| Header | What it does when present |
|---|---|
| Strict-Transport-Security (HSTS) | Once received, tells the browser to use HTTPS for subsequent connections to the domain for a set period. It protects visits after the first one; without preloading, the very first connection before HSTS has been received is not covered. |
| X-Frame-Options | Restricts whether a page can be framed by another site. CSP's frame-ancestors directive is the more modern and flexible control, so a response without X-Frame-Options may still have effective protection against framing if CSP is present. |
| X-Content-Type-Options | Tells the browser to trust the declared Content-Type rather than guess a file's type from its content, which prevents MIME-sniffing. |
| Content-Security-Policy (CSP) | An additional, browser-enforced restriction on which sources a page may load scripts, styles, and other resources from. Its absence removes one layer that can limit the impact of an injected script; it doesn't mean every injected script automatically runs unchecked. |
| Referrer-Policy | Sets a deliberate, explicit policy for how much of the referring URL is passed to the next site on click-through. Modern browsers apply a default referrer policy even without this header; setting it explicitly replaces that default with a policy the site has chosen. |
| Permissions-Policy | Narrows which origins or embedded documents may request specific browser capabilities (camera, microphone, geolocation, and others). Using one of these capabilities still requires user permission and the browser's own default allowlists still apply; this header is an additional restriction on top of those. |
| X-XSS-Protection (deprecated) | Controlled an old browser-side XSS filter that modern browsers have removed; current guidance in some cases recommends disabling it rather than setting it. We measured it for completeness, not as a current control. |
The full distribution
The distribution is heavily concentrated at zero, followed by an uneven spread across the remaining scores.
| Headers present | Observations | Share |
|---|---|---|
| 0 of 7 | 26,673 | 47.4% |
| 1 of 7 | 5,352 | 9.5% |
| 2 of 7 | 4,578 | 8.1% |
| 3 of 7 | 6,659 | 11.8% |
| 4 of 7 | 3,595 | 6.4% |
| 5 of 7 | 5,212 | 9.3% |
| 6 of 7 | 2,957 | 5.3% |
| 7 of 7 | 1,225 | 2.2% |
This is the original seven-header measurement, including the deprecated X-XSS-Protection header. A six-header distribution, current controls only, would need the underlying scoring rebuilt; we haven't done that for this article, so we're presenting the seven-header figures as what the data currently supports.
Adoption by individual header
Adoption isn't even across the seven. The two single-value headers, where the correct setting is close to the same line of config on most sites regardless of what the page does, are the best adopted. The headers that require a decision about what the specific page loads or accesses trail behind.
| Header | Present | Share |
|---|---|---|
| X-Content-Type-Options | 21,726 | 38.6% |
| X-Frame-Options | 20,539 | 36.5% |
| Strict-Transport-Security | 17,713 | 31.5% |
| Referrer-Policy | 14,831 | 26.4% |
| Content-Security-Policy | 10,678 | 19.0% |
| X-XSS-Protection (deprecated) | 9,785 | 17.4% |
| Permissions-Policy | 5,970 | 10.6% |
X-Content-Type-Options and X-Frame-Options need close to the same setting on most sites regardless of what the page does. Content-Security-Policy and Permissions-Policy require working out what the specific page actually loads and does before you can set a correct value, which is presumably part of why they trail.
The WAF/CDN association
We also recorded which observations sat behind a detected web application firewall or CDN edge. 17,059 observations had one detected; the remaining 39,192 did not.
This is an association, not a causal claim. Companies that use a detected edge provider may differ in other ways from companies that don't, and we haven't tested whether using one causes better header adoption. What the data does show is that a detected edge provider is not a guarantee these headers are present: even behind a detected WAF or CDN, roughly one in five observed responses contained none of the seven headers. This measurement cannot determine whether that reflects configuration at the origin, at the edge, or both; we only see the response as it arrived, not which layer set or omitted each header. Detection itself is based on recognisable response fingerprints and is a floor, not a ceiling: a WAF or CDN that leaves no recognised fingerprint in the response is classified as undetected here, whether or not one is actually present.
Which edge providers we detected
Among observations with a detected provider, our current fingerprint rules identified the following.
| Provider | Observations |
|---|---|
| Cloudflare | 13,949 |
| CloudFront (AWS) | 1,399 |
| Akamai | 543 |
| Imperva | 464 |
| Azure Front Door | 343 |
| Sucuri | 254 |
| Incapsula | 96 |
| Fastly | 9 |
| Varnish | 2 |
Our detection assigns a single fingerprint match per observation, so these rows describe distinct detected observations rather than overlapping counts. Among providers identified by our current fingerprint rules at meaningful volume, every identified parent company was US-headquartered. This describes what our fingerprinting identified, not every provider operating behind every domain: providers that leave no fingerprint our rules recognise are classified as undetected, and this analysis does not establish that no European provider was present in the undetected share. It's a narrower finding than "no European providers exist," and we're not making that broader claim. For a European vendor selling edge infrastructure or application security, it's still a useful, specific data point: among the providers our current rules can identify, the detected share is entirely non-EU.
Country breakdown
We cut the same seven-header check by the tracked entity's registered country, restricted here to countries with at least 1,000 observations in our data.
| Country | Observations | 0 of 7 | 7 of 7 |
|---|---|---|---|
| Poland | 6,789 | 56.7% | 3.2% |
| Italy | 4,164 | 51.9% | 1.2% |
| Spain | 2,491 | 52.2% | 1.9% |
| United States | 10,072 | 47.8% | 1.9% |
| France | 4,790 | 48.6% | 2.0% |
| Germany | 11,205 | 41.7% | 1.8% |
| United Kingdom | 1,202 | 44.5% | 3.5% |
| Netherlands | 5,167 | 26.3% | 2.8% |
This table is descriptive, not a national security ranking. Poland has the highest zero-header share among the countries shown (56.7%) and the Netherlands the lowest (26.3%), but we haven't controlled for the industries, company sizes, domain selection, hosting patterns, or observation dates represented in each country's cohort, any of which could account for some or all of the difference. We're not inferring that one country has better security maturity than another from this table alone.
Why this finding matters
None of these seven headers require buying a security product. Some, the single-value ones like X-Content-Type-Options and X-Frame-Options, are close to a one-line configuration change. Others, particularly a correctly scoped Content-Security-Policy or a site-wide HSTS rollout, can require testing against the application's actual behaviour and a staged rollout, since a misconfigured CSP can break legitimate functionality. The point isn't that every gap here is trivial to close; it's that none of the seven require a vendor relationship, only someone's attention.
A zero-header response may reflect an ownership or configuration gap rather than a technically difficult or heavily resourced security problem. That is what makes the result feel closer to unopened mail than an unsolved engineering challenge, though our data can't establish why any specific response came back the way it did.
Method note
Source: CipherCue's own HTTP header observations (direct requests to each tracked entity's primary domain), not a third-party dataset or scanner. 56,251 observations across 50,769 distinct companies, most recently observed between 2026-03-26 and 2026-08-03.
Unit of analysis: figures in this article are a share of the 56,251 checks, not a share of the 50,769 companies. A small number of domains were checked more than once within the window and each check is counted separately; we have not deduplicated to one latest observation per company.
Scoring: a header counts as present if it appears in the response with any non-empty value; we do not grade the quality or correctness of the configured value.
Response type: our data does not consistently record whether a captured response was a redirect, the final HTML document, an error page, or a bot-block response, and headers can legitimately differ between these response types.
X-XSS-Protection is deprecated in current browsers; we measured it for completeness and do not treat it as equivalent to the other six headers in this article's discussion.
WAF/CDN detection depends on recognisable response fingerprints and is a floor, not a ceiling: a provider that leaves no recognised fingerprint is classified as undetected here, whether or not one is present.
Country refers to the tracked entity's registered country in CipherCue's data, restricted here to countries with 1,000 or more observations; smaller countries are omitted from the table but included in the overall totals above.
Finding this in your own market
CipherCue makes this same kind of public infrastructure and configuration signal filterable by country, industry, company, and detected infrastructure vendor. It's built as a research and prospecting tool for technology vendors trying to understand a target market, not as a claim about the security of any specific company appearing in it, and a missing header on its own isn't a sales opportunity without further qualification.