Website security statistics: what we found on 93 real websites

Each row has its own sample, because not every check works on every domain. A site that blocked us has no header data, and a subdomain has no DMARC record of its own. The last column is how we usually rate the issue in a written audit report when it is the only problem. Real severity depends on the site.

Security headers are short instructions a website sends with every page. They tell the browser to use HTTPS only, to refuse to load the page inside another site, and which scripts it may run. Most cost nothing and take minutes to add, yet they were the most common gap in our data. We checked six headers on the home page of each site, using the list from the OWASP Secure Headers Project.

How many headers each site was missing

The spread matters more than the average. Most sites were either nearly complete or nearly empty.

The median site was missing 5 of the 6. Shares are rounded, so they add up to 99%.

A CDN does not fix it for you

16 of the 49 sites ran behind Cloudflare. 5 of those 16 were still missing all six headers, against 14 of the 33 sites that were not behind Cloudflare. A content delivery network can add some headers, but only when someone turns those settings on.

We detect the platform from signatures on the home page, so a site that hides its platform lands in “other or not detected”. The groups are small, so read this table as a direction, not a ranking.

Two things stand out. Sites built on Next.js were missing far fewer headers on average. And WordPress made up only 6 of 49 sites, far below its share of the web as a whole. Our sample leans towards custom-built sites, so do not read it as a picture of WordPress security. Our WordPress audit page covers what we look for there.

SPF lists the servers allowed to send your mail. DMARC, defined in RFC 7489, tells receiving mail servers what to do with mail that fails those checks, and it is the record that protects the From address people actually see. Without it, it is much easier for anyone to send an invoice or a password reset that appears to come from your exact domain.

• SPF was common. More than 9 in 10 of the 67 domains published an SPF record.
• DMARC was not. 20 of 67 domains (30%) had no DMARC record at all.
• Few blocked forged mail. For 18 domains we also read the DMARC policy. 5 used p=reject, which blocks forged mail. 6 used p=quarantine, which sends it to spam. 7 had p=none or no record, so forged mail could reach the inbox.

You can check your own domain with the free email spoofing checker. It reads the same records.

Every subdomain (shop, staging, mail, old-admin and so on) is a separate thing an attacker can find and test. We count them from public sources only: certificate transparency logs, passive DNS datasets, web archives and DNS lookups of common names.

• The median domain had about 10 subdomains in public records. The median number still resolving was about 8.
• Half of the 62 domains (31) had 10 or more.
• 11 domains (18%) had 50 or more.

A long list is not a flaw by itself. The risk is the forgotten one: a test site with real data, or an old tool nobody patches. The free subdomain finder shows you yours.

Everything above is visible from outside without logging in or sending a single attack. That is also its limit. A passive check cannot tell you:

• Whether your plugins, themes or libraries are out of date in ways that matter.
• Whether an admin panel, backup file or test page is reachable somewhere other than the home page.
• Whether a logged-in user can see or change another user’s data.
• Whether forms, logins and payments can be abused.
• How your TLS (HTTPS) settings hold up in detail.

Those are the findings that tend to rate high or critical, and they need a person testing the site with permission. That is what our manual audit report covers. See manual vs automated testing for the difference.

The common problems in this data are cheap to fix. In order of effort:

• Add the security headers. Most hosts and CDNs let you set them in a settings screen. Start with HSTS, X-Content-Type-Options and X-Frame-Options, then write a Content-Security-Policy. Check the result with the free security headers checker.
• Publish DMARC. Start with p=none and a report address, read the reports for a few weeks, then move to quarantine and finally reject.
• List your subdomains and delete what you do not use. Old staging and test sites are a common way in.
• Then test the parts a scanner cannot see. The headers and DNS records are the visible tip. If your site has logins, customer data or payments, have a person test it.

• Source. Bug Circuit’s free passive check and free tools. They read public information only: the home page response, DNS records and public subdomain sources.
• Window. Domains first checked between 17 July and 16 October 2026. Data pulled on 16 October 2026. Each domain is counted once, using the latest result of each check.
• Sample. 93 distinct domains, after removing our own domains, staff test entries, temporary preview and sandbox hosts, dynamic DNS hosts and entries marked as spam. 42 (45%) were .com domains and 18 (19%) were Sri Lankan .lk domains.
• Headers. 49 sites whose home page returned HTTP 200. Sites that blocked us, timed out or did not respond are left out rather than counted as missing everything.
• Email. 67 registered domains with working DNS. Subdomains are left out because SPF and DMARC are published on the main domain. The DMARC policy was read for the 18 domains checked with the email spoofing tool.
• Subdomains. 62 domains where at least one public source returned results.
• Bias. These are domains people chose to check, not a random sample of the web. Some will be the checker’s own site, so the group may be more security-aware than average, or more worried.
• Privacy. No domain names, no finding details and no group smaller than 5 are published. Our paid manual audits are not included yet: there are still too few to publish without a risk of pointing at a customer.

How to cite: Bug Circuit, “Website security statistics 2026”, bugcircuit.com/guides/website-security-statistics, data as of 16 October 2026.