What We Measured
Data collection window:
- Last 90 days: 254,578 scans across 159,649 unique small-business WordPress sites
- Last 30 days: 84,071 scans across 81,474 unique small-business WordPress sites
Scans tested for:
- SSL/TLS configuration quality: Not just whether HTTPS is present, but:
- Valid certificate
- HTTP Strict Transport Security (HSTS)
- Modern TLS version (TLS 1.2/1.3, not SSLv3 or TLS 1.0/1.1)
- Strong cipher suites
- TLS protocol versioning gaps: Whether old, insecure protocols are still allowed
- Related checks: Security headers, mixed content, server version exposure
Definitions:
- "Good" SSL/TLS: All requirements above met—much stricter than just "has HTTPS."
- "Good" TLS Protocol Security: No weak or obsolete protocol is enabled.
Key Findings
Overall Grade Distribution
Graded security scans (30-day window):
| Grade | Site Count | Percentage |
|---|---|---|
| A | 266 | 0.3% |
| B+ | 1,248 | 1.5% |
| B | 851 | 1.0% |
| C+ | 17,963 | 21.4% |
| C | 9,619 | 11.4% |
| D | 22,165 | 26.4% |
| F | 23,923 | 28.5% |
The majority of WordPress sites scanned graded D (26.4%) or F (28.5%). Less than 2% reached a B or better.
SSL/TLS Configuration Gaps
| Check | Pass Rate ("Good") | Notes |
|---|---|---|
| Security Headers (all) | 0.3% | All required headers present/configured |
| Cookie Security | 81.5% | Secure flag, SameSite, HttpOnly on session cookies |
| Mixed Content | 62.8% | No mixed HTTP/HTTPS requests found |
| Server Version Leak | 1.3% | “Good” = server does not expose version information |
TLS Protocol Security
| Status | Graded Scans | Percentage (30d) |
|---|---|---|
| Info/Weak | 4,241 | 5.0% |
A TLS protocol is “Good” if only strong, modern protocols (TLS 1.2 or 1.3) are supported. The remaining 5.0% still allow weak or obsolete versions (SSLv3, TLS 1.0/1.1).
Why Weak TLS Protocols and Incomplete SSL Hurt WordPress Security
What Makes This A Compound Exposure?
A WordPress site with a valid SSL certificate is not automatically secure. If the configuration allows outdated TLS protocols or fails to enforce HSTS and strong ciphers, attackers can target known downgrade, interception, or replay techniques—especially on shared networks or by abusing browser fallback behaviors.
- Weak TLS protocol support (like TLS 1.0 or SSLv3) enables attackers to force connections over older, vulnerable versions, bypassing modern cryptographic protections.
- Missing SSL hardening (e.g., no HSTS or weak cipher priority) means browsers may not enforce secure connections or may accept connections that can be intercepted.
When both gaps appear together (as in the 94.1% of sites that failed "Good" SSL/TLS), the risk is amplified:
Attackers can use automated tools to connect via a weak protocol and use that as leverage in attacks, such as POODLE (CVE-2014-3566), which exploited SSLv3 fallback, or BEAST, which targeted TLS 1.0.
Well-Documented Attack Pattern:
Tools like sslscan and testssl.sh routinely map out supported protocols and ciphers for every domain. Shared exploit kits cross-reference this data with public vulnerabilities corresponding to each version and cipher suite.
Practical Business Implications
- SEO and Trust: Browsers directly warn visitors when a site permits insecure connections. This reduces conversions and trust.
- Compliance: PCI DSS and other frameworks require modern TLS for payment data. Sites failing to disable old protocols may fall out of scope—without warning.
- Downtime: Mass scanning tools hunt for weak configurations—compromised sessions, credential interception, and forced logouts can all result from weak protocols.
How This Exposure Gets Used in Real Exploits
Example:
In the POODLE vulnerability (CVE-2014-3566), attackers exploited the existence of SSLv3 as a fallback protocol. Simply having “SSL support” was not enough: it was the simultaneous presence of a seemingly “secure” certificate and an old protocol that let attackers intercept and decrypt data.
Attack Chain:
- Find a site with HTTPS and weak SSL/TLS protocols enabled.
- Force a connection downgrade (via network tricks or browser behavior).
- Use a known cryptographic attack to access sensitive session or authentication data.
Automated scans make this process rapid and largely invisible to most website owners—until browser warnings, user drop-off, or security incidents force a response.
Why Most WordPress Sites Fail This Check
- Default configurations: Many hosting providers enable a broad set of TLS protocols and ciphers for compatibility, but do not tune for security.
- Auto-renew SSL: Automating certificates keeps HTTPS up, but doesn’t address protocol or cipher hardening.
- Lack of visibility: Unlike mixed content or plugin updates, protocol settings are invisible in the WordPress dashboard. Most operators never see or check their site's TLS/SSL posture.
- Shared environments: On shared or managed hosts, your "SSL configuration" is often a global setting, not unique to your site.
What Good SSL/TLS Actually Looks Like
To earn a "Good" SSL/TLS rating (only 5.9% of sites did), a WordPress site must meet all—not just some—of these requirements:
| Requirement | Why It Matters |
|---|---|
| HSTS (Strict Transport) | Stops downgrade attacks, ensures HTTPS |
| TLS 1.2/1.3 Only | Disables known-broken protocols |
| Strong Cipher Suites | Blocks weak cryptographic methods |
What You Can Do Right Now
1. Check your site’s SSL/TLS configuration:
Run a website security scan that tests for protocol versions, HSTS, and cipher order—not just valid certificates.
2. Upgrade your server configuration:
- Remove support for SSLv3, TLS 1.0, and TLS 1.1
- Enable only TLS 1.2/1.3
- Prefer modern ciphers (disable RC4, 3DES, etc.)
3. Enforce HSTS:
Add the Strict-Transport-Security header to tell browsers to always use HTTPS, blocking downgrade attempts.
4. Ask your host for help:
If you don’t manage your own server, provide them with scan results and ask for confirmation on their TLS policy.
5. Monitor regularly:
TLS standards evolve. Schedule automated scans so configuration drift or host-wide changes don’t leave you exposed in the future.
FAQ
Isn’t my site safe if I have an SSL certificate and users see the padlock?
Not always. The padlock means there is some encryption, but it does not guarantee strong protocols, strict transport, or hardened ciphers. Only a robust SSL/TLS posture blocks downgrade and interception attacks.
What’s the difference between HTTPS and strong SSL/TLS?
HTTPS simply means encrypted transport is possible. Strong SSL/TLS requires using only secure protocols, forbidding old versions, enforcing HSTS, and preferring strong ciphers—all at once.
My hosting provider manages SSL. Can I still be at risk?
Yes. Many managed environments trade off broad compatibility for strict security, leaving weak protocols enabled by default. Always ask for specifics: Which protocols and ciphers are supported? Is HSTS enforced?
If I run an online store with WooCommerce, am I at extra risk?
Online stores face additional compliance burdens (e.g., PCI DSS requires TLS 1.2+). Failing SSL/TLS configuration may impact trust, conversion rates, and even payment processor eligibility.
Final Thoughts
Across 84,071 scans of small-business WordPress sites in the last month, only 5.9% achieved a fully secure SSL/TLS configuration. Relying on simple HTTPS presence is not enough. Weak TLS protocols and incomplete SSL hardening often coexist—creating a practical attack surface that automated tools routinely exploit.
While the technical fixes require server-level changes, the process begins with visibility. Regular, external website security scans highlight exactly where your SSL/TLS posture needs work. Identify gaps, update your configuration, and re-scan to validate that you—and your customers—are protected based on today’s standards.
Take the first step: scan your WordPress site for SSL/TLS protocol weaknesses now. Your users’ trust, your compliance status, and your conversion rate depend on closing this avoidable gap.