RACKCRUNCH drew 7,040 random rows from the Curlie web directory of US local businesses, made two HTTPS request-chain scans of each, and read the response headers only. Of the 4,688 unique domains that returned HTTP-200, 49.7% met none of the seven study-defined header criteria. The more useful finding is what happened when they stopped counting headers and started parsing them.

Per control, on that base:

  • HSTS present on 43.8% of sites, but strong HSTS — at least a year plus includeSubDomains — on only 12.3%, and 45% of those passes sit on a www host that does not cover the bare domain
  • X-Content-Type-Options: nosniff on 39.7%, clickjacking protection with a recognized restrictive value on 31.2%
  • Explicit non-wildcard Permissions-Policy on 8.0%, recognized non-default COOP on 1.1%
  • Referrer-Policy missing on 86.6%, which is less alarming than it sounds: browsers fall back to a secure default, and the real problem is explicit weak legacy values (5.4%)
  • Version disclosure via Server, X-Powered-By or ASP.NET headers on 20.5% — graded low severity on purpose, since hiding a version number patches nothing

The Content-Security-Policy result then falls apart under inspection:

  • 21.2% send an enforced CSP, which reads as respectable
  • 47.1% of those policies are one of three strings — frame-ancestors 'self', the Shopify platform default, or bare upgrade-insecure-requests — none of which contains a script directive
  • After writing a parser and reading the policies: 17.2% have no script-restricting directive, 4.0% restrict scripts, and 8 domains (0.17%) pass the header-only script-CSP rule
  • Of the 186 script-restricting policies, 172 were undone by an effective unsafe-inline and 157 by unsafe-eval

Where the posture comes from is the part with a lever attached. Sites labeled by their headers: 100% of Shopify-labeled sites had a clickjacking header and nosniff and 0% had strong HSTS; 100% of GoDaddy-builder sites had strong HSTS and 0% had nosniff. For a large slice of the web, header configuration is a hosting-platform default, not an owner decision.

Two other things are worth noticing. The authors published a section titled “We got one thing wrong”: an earlier draft claimed six sites met all eight criteria, the rubric had double-counted frame-ancestors, and the corrected answer is one. And 19.9% of sampled rows — one in five — produced no usable HTTPS response at all: TLS failures, redirects to plain HTTP, timeouts, dead DNS. Nothing can be said about the headers of a site you cannot reach.

The takeaway is that header counts measure adoption of checkboxes, not protection. The value is in reading the policy and asking what it actually does — and, for most small-business sites, the cheapest fix is better defaults in the site builder rather than education for the owner.