What We Measured
This report draws from 91,179 website security scans conducted between July 11 and August 10, 2026, spanning 52,560 unique small-business WordPress sites. The scans checked several foundational configuration areas, focusing here on security headers—small HTTP response settings that direct browsers to block or prevent common types of online attacks.
The "Security Headers (all required)" check only awards a "Good" score if a site sends all of these headers, correctly configured:
- Content Security Policy (CSP): Restricts which scripts, images, and resources can be loaded, the most effective browser control against XSS.
- X-Frame-Options: Prevents clickjacking by disabling site embedding in iframes.
- X-Content-Type-Options: Stops browsers from incorrectly interpreting file formats, reducing drive-by download risk.
- Referrer-Policy: Controls what visitor referral data is shared to external sites, increasing privacy and reducing information leakage.
If any of these headers are missing or misconfigured, the site fails the "Good" criteria.
Key Findings
Security Headers Configuration: Stark Gaps
Out of 17,585 measured scans:
- Only 0.4% rated "Good" for security headers—all critical headers present and configured correctly.
- This means 99.8% either omit one or more required headers, have them partially set, or configure them in a way that doesn’t block major attack vectors.
How Sites Landed in Each Grade (30-Day Snapshot)
| Grade | Graded Scans | Percent |
|---|---|---|
| A | 400 | 0.4% |
| B+ | 1,238 | 1.4% |
| B | 588 | 0.6% |
| C+ | 17,805 | 19.5% |
| C | 7,649 | 8.4% |
| D | 22,635 | 24.8% |
| F | 30,623 | 33.6% |
The overwhelming majority of WordPress sites landed in D or F due in part to missing or misconfigured security headers. A minuscule 0.4% of sites hit the "Good" mark for this check.
Broader Security Configuration vs. Basics
Other security signals reveal a similar trend:
- Cookie Security (Secure, HttpOnly, SameSite flags): 81.9% rated Good—most sites get this inexpensive win.
- SSL/TLS Hardening: Only 5.5% rated Good (valid cert + HSTS + modern TLS + strong ciphers). Most sites have HTTPS, but fall short on strict settings.
- No Version Leak (Server Banner): 1.3% rated Good—version exposure remains common.
- Content Security Policy Only: 0.0% rated Good—almost no sites have a strong CSP.
Takeaway:
Sites are adding SSL and setting basic cookie controls, but stopping short of the browser-side protections that address XSS and content injection.
Why Security Headers Matter: XSS and Content Injection
Security headers act as guardrails—machine-readable instructions that tell browsers how to behave if hackers try to inject code.
The XSS Risk with Missing Headers
Cross-site scripting (XSS) lets attackers run malicious scripts inside your visitors' browsers. The impact ranges from defaced interfaces to malicious redirects and data theft. XSS vulnerabilities often arise from plugin flaws or theme bugs, but even fully patched sites remain vulnerable to attack chains if they skip browser-enforced policies.
Fact:
Security headers are the browser-side fail-safe against XSS—especially when server-side code validation is imperfect, which is frequently the case in real-world WordPress plugins and themes.
Real-World Example: CVE-2023-4160
In August 2023, CVE-2023-4160 targeted a popular WordPress plugin with a reflected XSS vulnerability. Browsers set to enforce a CSP or X-Content-Type-Options header would have blocked the malicious payload, even though the underlying plugin flaw was not patched instantly by all site owners. Sites lacking these headers had no browser defense.
Why Is Configuration Still Lagging?
Most WordPress hosts enable HTTPS by default, but rarely enforce strict SSL hardening or set recommended headers. Plugins exist to help, but many require manual install and careful tuning—extra steps that fall through the cracks for busy site owners or agencies juggling dozens of installs.
What a Good Security Headers Setup Looks Like
A minimum viable configuration recommended by security standards (OWASP, Mozilla) typically includes:
| Header | Function | Basic Example |
|---|---|---|
| X-Content-Type-Options | Blocks MIME type sniffing | X-Content-Type-Options: nosniff |
| X-Frame-Options | Prevents clickjacking | X-Frame-Options: SAMEORIGIN |
| Referrer-Policy | Controls referrer data | Referrer-Policy: no-referrer-when-downgrade |
Without these, browsers follow default, less secure behaviors that leave visitors at risk.
Common Misconceptions
Myth:
"My site is behind HTTPS. That means it’s safe."
Reality:
HTTPS encrypts data in transit but does not instruct the browser to block malicious content or scripts. Security headers fill this gap.
Myth:
"WordPress is updated, so I don’t need extra headers."
Reality:
Plugin or theme bugs create XSS risk even on the latest WordPress versions. Security headers are an additional line of defense, working regardless of patch timing.
Myth:
"Setting these headers is complicated and could break my site."
Reality:
Some headers (like X-Content-Type-Options) are virtually risk-free to add. CSP requires more testing but can start with a loose policy that is tightened over time.
What You Can Do Right Now
Scan Your Site
Run a website security scan that checks for missing security headers, in addition to plugin vulnerabilities and SSL issues. Automated scans reveal your configuration in minutes, highlighting practical, fixable gaps.Review Your Host’s Controls
Some managed WordPress hosts enable basic headers by default—ask support or check their settings. If not, most provide a way to add custom headers via .htaccess, nginx config, or a headers plugin.Deploy a Security Headers Plugin
For non-technical site owners and agencies, security plugins can set X-Frame-Options, X-Content-Type-Options, and Referrer-Policy with minimal configuration. CSP may need additional tuning to account for scripts or embedded content your site relies on.Test Before and After
After any header change, use your site and check for broken images or scripts. Start with non-blocking reports (“Content-Security-Policy-Report-Only”) before enforcing a strict policy.
FAQ: Security Headers and WordPress
Q: Are security headers required for PCI, GDPR, or other compliance?
A: While not always explicitly listed, strongly configured headers help with compliance by reducing XSS, clickjacking, and data leakage—common audit findings.
Q: Will security headers slow down my site?
A: No. They are small text instructions in the HTTP response, with negligible performance impact.
Q: Can security headers replace a web application firewall or patching?
A: No. Headers are an additional safeguard, not a replacement for patching vulnerable plugins or using a WAF.
Q: What if my site is managed by an agency?
A: Ask your agency for a scan report including security headers coverage. Most can add these with minimal impact.
Final Thoughts
The data from 91,179 scans shows a striking 99.8% gap in effective security headers configuration among WordPress small-business sites. This is not a theoretical concern—recent CVEs and attack patterns prove that browser-side controls like CSP and X-Content-Type-Options can contain or block real-world attacks before visitors are affected.
Despite broad adoption of HTTPS and basic cookie controls, most WordPress sites still lack this vital layer, primarily due to configuration complexity and low visibility in standard hosting setups.
Regular website security scans help pinpoint missing headers and other silent misconfigurations—providing an actionable starting point for both agencies and solo founders looking to harden their WordPress installs.
What You Can Do: Prioritize Security Headers Now
If you operate or manage WordPress sites, use a website security scan today to audit your security headers and receive step-by-step remediation guidance. This simple step closes a critical gap that, for 99.8% of WordPress small business sites, remains unaddressed.
For additional fast-wins in WordPress security, see our practical guide to quick security improvements.
Taking just one of these steps can reduce avoidable risk and help insulate your users from browser-based attack techniques that automated scans—and threat actors—look for as a starting point.