Nearly All Scanned WordPress Sites Run Without an Enforced CSP

Short answer: Between August 30, 2026 and September 29, 2026, ThreatSpot's external scanner found an enforced, correctly configured Content-Security-Policy (CSP) header on 30 of 80,834 eligible CSP checks — fewer than one in a thousand. In other words, 100.0% of eligible checks did not meet the "Good" CSP standard. What the scan cannot tell you is why — and it cannot tell you what would happen if those sites deployed CSP tomorrow.

This article replaces an earlier version that asserted sites skip CSP for reasons other than incompatibility. Our scanner measures policy presence and static configuration from response headers; it cannot establish why a site runs without CSP, and that assertion has been removed. Read the full correction.

What We Measured

ThreatSpot performs external security scans: it requests the site and inspects the response headers, then parses the Content-Security-Policy for directive-level problems.

• Observation window: August 30, 2026 to September 29, 2026 (30 days)
• Cohort: 80,789 unique sites in the ThreatSpot scanning programme; 80,835 scans ran in the window
• Eligible CSP checks: 80,834 scans where the CSP check actually ran (blocked or skipped checks are excluded from the denominator)
• What "Good" means here: an enforced Content-Security-Policy header was present and the parsed policy had no directive-level issues

Two things this method deliberately does not do:

1. It does not load the site in a browser, so it cannot observe whether a policy breaks page functionality.
2. It observes the enforced Content-Security-Policy header specifically. A site experimenting with Content-Security-Policy-Report-Only (a separate header) would not register an enforced policy.

Key Findings

• Fewer than one in a thousand eligible CSP checks rated Good — 30 of 80,834 scans where the check ran.
• 0.6% of eligible checks rated Good on the overall security-headers check — 445 of 80,835. The headers check covers the recommended set of browser-facing headers.
• The dominant pattern is absence, not misconfiguration: almost all non-Good CSP results were sites with no enforced CSP header at all, rather than policies present but flawed.

Read carefully, these numbers describe adoption in our scanned cohort. They are not evidence about compatibility, operator intent, or effort.

What This Does Not Mean

This is the part our earlier version got wrong, and it is worth being precise about.

• Absence does not prove no one tried. A passive scan cannot see attempts, rollbacks, hosting-provider defaults, or internal decisions. Some operators may have tested CSP and backed it out; some may never have considered it. The data does not distinguish these cases.
• We did not measure breakage. Sites without an enforced CSP cannot exhibit CSP-induced breakage, so "we found almost no CSP-related breakage among sites without CSP" is not a meaningful compatibility result. Nothing in this dataset supports a claim that compatibility is or is not the barrier.
• This is not a random sample of WordPress sites. ThreatSpot's scanned cohort skews toward small-business sites discovered through public-web scanning, so rates here may differ from the broader WordPress population.
• A missing CSP is a missing mitigation layer, not proof of compromise. It widens exposure to content-injection and script-based risks; it does not mean the site has been attacked.

How to Deploy CSP on a Plugin-Heavy WordPress Site

CSP restricts where scripts, styles, and other resources may load from. WordPress sites commonly rely on inline scripts and third-party resources injected by themes and plugins, so a strict policy applied without preparation can break functionality. That is a real trade-off, and it is exactly why gradual deployment is the standard recommendation:

1. Start in report-only mode. Serve Content-Security-Policy-Report-Only first. The browser logs violations without blocking anything, so you can observe what a policy would affect on a fully loaded, plugin-active site.
2. Review the violation reports and identify which plugins or themes inject inline scripts or load unexpected origins.
3. Tighten incrementally. Move to an enforced policy with nonces or hashes for your own inline scripts, then progressively restrict script-src and other directives.
4. Re-test after plugin updates. Plugin updates can introduce new inline scripts or origins that an existing policy does not allow.

If you manage many sites, test on a representative client site before rolling a policy template across the portfolio.

FAQ

Does a missing CSP mean my site is insecure? It means one defense-in-depth layer against content injection and script-based attacks is not active. Security is layered — TLS, header hygiene, updates, and access controls all matter alongside CSP.

Will CSP break my WordPress site? It can, if you enforce a strict policy without testing on a site whose plugins and themes depend on inline scripts or third-party origins. Report-only mode exists precisely so you can find those conflicts before blocking anything. We have not measured breakage rates; this is deployment guidance, not a measured result.

What exactly did the scan check? The presence of an enforced Content-Security-Policy response header and a static review of its directives — nothing more. Browser-level compatibility is outside the scan's method.

Why did you correct this article? The earlier version drew conclusions (about compatibility and operator effort) that our measurement method cannot support. We now state only what was measured, with the window and denominator made explicit.

About This Research

• Source: ThreatSpot external scan telemetry (August 30, 2026 to September 29, 2026)
• Denominators stated explicitly: 80,835 scans in window; 80,789 unique sites covered; 80,834 eligible CSP checks; 80,835 eligible header checks
• Method: external observation of response headers plus static CSP directive review; no browser rendering, no compatibility testing, no operator-intent data
• Limitations: scanned cohort is not a random sample of WordPress sites; repeated scans of the same site are not deduplicated in the scan count; report-only policies are not detected as enforced CSP
• Analysis and drafting are automated and editorially reviewed. This article was corrected on September 29, 2026 to remove unsupported claims; the numbers above are drawn directly from the scan database for the stated window.

Sources

• MDN Web Docs: Content Security Policy
• MDN Web Docs: Content-Security-Policy-Report-Only
• ThreatSpot WordPress Security Index — live aggregate scan telemetry