Website Security Statistics 2026: Data, Risks & Trends

Key Website Security Statistics for 2026

The table below is designed for citation rather than shock value. Each statistic states what the denominator represents, because a percentage of HTTP requests cannot be compared directly with a percentage of websites, applications, vulnerabilities, or confirmed breaches. The most useful 2026 picture comes from combining web-crawl telemetry, application-attack telemetry, vulnerability research, breach investigations, CMS data, and malware scanning without treating those datasets as if they measured the same population.

What Website Security Statistics Actually Measure

A website can be secure in one metric and exposed in another, so the first rule is to keep the denominator visible. A crawl of public websites measures configuration and technology adoption. A web application firewall measures requests and attacks passing through a protected customer population. A vulnerability database counts disclosed software flaws. Malware scanners count sites that match infection signatures. A breach report counts investigated incidents or confirmed breaches. None of these alone tells us “what percentage of websites are secure.”

This distinction is the core methodology of this report. It prevents a common error in website security statistics: taking a number from one stage, such as a 31% breach-entry rate for vulnerability exploitation, and presenting it as though 31% of websites contain exploitable vulnerabilities. The Verizon number is a breach denominator, not a website denominator.

How Secure Is the Web in 2026?

The web is more encrypted and more security-aware than it was a decade ago, but it is also more automated and more dependent on third-party software. Report URI’s ten-year research is unusually useful because it has crawled the top one million sites daily since 2016 using the same continuing series. In its June 13, 2026 snapshot, 819,002 sites responded. Of those, 658,038, or 80.3%, redirected to HTTPS. That is a substantial improvement in transport security, but HTTPS only protects data in transit. It does not prevent broken access control, vulnerable plugins, credential abuse, malicious uploads, or server-side compromise.

Application-layer defenses show a similar pattern. Report URI observed 170,057 Content Security Policy configurations, up from roughly 1,400 sites in 2016. Yet adoption alone is not equivalent to effectiveness: 46.8% of observed policies still contained unsafe-inline and 41.9% contained unsafe-eval, both of which weaken CSP’s ability to restrict script execution. The strongest lesson from the ten-year data is that security controls can become more common while configuration quality remains uneven.

Website Security Statistics by Year

There is no single global “website security score” that can be plotted from 2023 through 2026. The defensible approach is to compare individual metrics only when the measurement method remains sufficiently consistent. Three trends are especially useful: automated traffic, WordPress ecosystem vulnerability disclosures, and web security-control adoption. They measure different layers, but together they show why the answer to “are websites getting safer?” is not a simple yes or no.

The direction is therefore mixed. Browser-facing security defaults and encrypted transport have improved sharply, while the volume of automated traffic and disclosed third-party vulnerabilities has also grown. More vulnerability disclosures can partly reflect better research rather than worse code, so disclosure counts should never be interpreted as a direct breach rate. The more important question is how quickly exposed weaknesses are patched compared with how quickly attackers exploit them.

Web Application Attack Statistics

Imperva’s Cyber Threat Index provides one of the largest recurring telemetry sets for web application risk. Its index is built from more than 25 petabytes of monthly network traffic, roughly one trillion HTTP requests, and about 30 billion monthly web application attacks observed through its global sensors and Cloud WAF service. These numbers are not a count of all attacks on the internet. They represent attack activity inside Imperva’s customer and sensor population, which makes the dataset useful for trends but not a global attack counter.

The scale still matters. Thirty billion attacks per month across a monitored application population illustrates why public-facing websites experience constant automated probing rather than occasional manual hacking. Attackers can enumerate exposed paths, test known CVEs, attempt credential stuffing, abuse business logic, and target APIs at machine speed. This is one reason a modern website security program has to be continuous rather than based on an annual audit.

For broader disclosure and exploitation data, ScanTitan’s Vulnerability Statistics research separates CVE volume, KEV status, exploitation timing, and severity so website owners can distinguish the existence of a flaw from evidence that attackers are using it.

Bot and Automated Traffic Statistics

Automation now represents the majority of internet traffic in the Thales/Imperva dataset. The 2026 Bad Bot Report, based on full-year 2025 activity, found bots generated 53% of web traffic and humans 47%. Bad bots alone accounted for 40%, up from 37% a year earlier. Thales also reported blocking 17.2 trillion bad-bot requests during 2025. Those figures describe requests, not unique attackers, and they include automation across many sites and applications.

The composition of bot traffic has security implications beyond scraping. Thales reported that 27% of bot attacks targeted APIs, while 21% targeted business logic. AI-enabled bot attacks rose 12.5-fold year over year in its telemetry. The practical shift is that websites increasingly serve three populations at once: humans, benign automation, and malicious automation. Security controls have to distinguish intent rather than simply block anything that is not a browser-driven human session.

DDoS and Website Availability Statistics

Availability is part of website security, and 2025 produced a major step-change in distributed denial-of-service activity. Cloudflare’s 2026 Threat Report says it observed and automatically mitigated 47.1 million DDoS attacks during 2025, up 121% year over year. That works out to an average of 5,376 attacks per hour inside Cloudflare’s network. The figure is not a count of every DDoS attack on the internet; it describes attacks visible to Cloudflare’s infrastructure and customers.

The growth was concentrated heavily at the network layer. Cloudflare reported 34.4 million network-layer attacks in 2025, compared with 11.4 million in 2024, while HTTP DDoS attacks reached 12.7 million. The combined annual series rose from 14.0 million attacks in 2023 to 21.3 million in 2024 and 47.1 million in 2025. That is a 236% increase from 2023 to 2025 using Cloudflare’s own continuing telemetry.

Attack size also escalated. Cloudflare recorded a 31.4 Tbps UDP flood in November 2025 that lasted 35 seconds and was, at publication, the largest publicly disclosed DDoS attack. During a separate hyper-volumetric campaign, HTTP floods exceeded 200 million requests per second. These figures show why website availability cannot be treated as an uptime-only problem: application and network traffic can remain technically legitimate at the protocol level while overwhelming origin infrastructure or business logic.

Primary source: Cloudflare 2025 Q4 DDoS Threat Report.

Website Vulnerability Statistics

Website vulnerability statistics are dominated by the software supply chain because a modern site is rarely one codebase. It may include a CMS, plugins, themes, JavaScript packages, APIs, authentication providers, payment components, analytics tags, and cloud services. OWASP’s 2025 Top 10 reflects that reality: Broken Access Control remains the number-one web application risk, Security Misconfiguration moved to number two, and Software Supply Chain Failures entered at number three. Injection remains in the top five, while Authentication Failures and Software or Data Integrity Failures remain separate major categories.

The 2025 OWASP data also shows why configuration deserves its own security metric. On average, 3.73% of applications in the contributed dataset had one or more weaknesses mapped to Broken Access Control, while 3.00% had one or more weaknesses mapped to Security Misconfiguration. Those percentages apply to OWASP’s contributed application-testing data, not all public websites.

The sharper operational signal comes from exploitation. Verizon’s 2026 DBIR found that 31% of breaches began with vulnerability exploitation, making software flaws the leading breach entry point for the first time in the report’s 19-year history. That result connects website vulnerability management directly to breach prevention: the risk is not merely that more CVEs exist, but that attackers are increasingly turning exposed weaknesses into initial access.

Website Vulnerability Exploitation Statistics

VulnCheck’s first-half 2026 exploitation research identified 495 CVEs with first-time evidence of exploitation. Importantly, that represented only 1.4% of the broader CVE population in its comparison, reinforcing a central vulnerability-management principle: most disclosed CVEs do not become equally important in the wild. CMS platforms were the largest technology target category in the dataset, with 163 known exploited vulnerabilities. That makes exploitation evidence especially relevant to website owners running common content-management software.

The same report found only 14 of 1,061 AI-discovered CVEs, or 1.3%, had evidence of real-world exploitation at the time of its analysis. The finding is useful because it separates vulnerability-discovery volume from actual attacker behavior. AI may accelerate discovery, but defenders still need to prioritize based on reachability, exposure, exploit evidence, privileges required, patch status, and business impact rather than the existence of a scanner finding alone.

This is why the most effective remediation queue is not simply “critical first.” A remotely exploitable internet-facing flaw with confirmed exploitation can deserve action before a higher-CVSS issue that is unreachable or requires privileged local access. ScanTitan’s research on exploitation and patching should be used alongside live asset inventory rather than as a substitute for it.

How Quickly Website Vulnerabilities Become Real Attacks

The gap between disclosure and exploitation can be short enough that patch cadence becomes a security control. A useful example is Adobe Commerce CVE-2024-34102, known as CosmicSting. Adobe released its security update on June 11, 2024 and later confirmed exploitation in the wild. Sansec subsequently reported that seven criminal groups had compromised 4,275 Adobe Commerce and Magento stores, approximately 5% of the platform population in its measurement, and planted payment skimmers on checkout pages. That figure applies to Sansec’s observed Adobe Commerce and Magento population, not ecommerce sites generally.

The incident also demonstrates why installing a patch is not always the end of remediation. Adobe’s later guidance required affected merchants to rotate encryption keys because attackers could have stolen secret keys before patching; leaving those keys valid could preserve attacker access. In September 2025, Adobe separately disclosed CVE-2025-54236 in Adobe Commerce and Magento Open Source and stated that it was being exploited in the wild. The lesson is operational: exploit evidence, credential or key rotation, persistence checks, and post-patch validation can matter as much as the patch package itself.

Primary sources: Adobe Commerce guidance for CVE-2024-34102, Adobe APSB25-88, and Sansec CosmicSting research.

CMS Website Security Statistics

Content-management systems deserve special treatment because platform reach changes the size of the exposed population. W3Techs reported in September 2026 that WordPress powered 40.7% of all websites and held 58.9% of the known-CMS market. Shopify accounted for 5.3% of all sites, Wix 4.2%, Squarespace 2.5%, Joomla 1.1%, and Drupal 0.7%. Those usage percentages are exposure metrics, not vulnerability rates. A platform’s market share tells us how widely a vulnerability could matter, not whether the platform is intrinsically insecure.

The more useful comparison separates core software from extensions and then asks whether exploitation is confirmed. ScanTitan’s CMS Vulnerability Statistics research does this across WordPress, Joomla, Drupal, Craft CMS, and related ecosystems instead of comparing raw CVE totals that use incompatible counting rules.

WordPress security statistics

Patchstack recorded 11,334 new WordPress ecosystem vulnerabilities in 2025, a 42% increase over 2024. It classified 4,124, or 36%, as serious enough to require mitigation rules and 1,966, or 17%, as high severity with elevated potential for automated mass exploitation. These figures cover the WordPress ecosystem, not WordPress core alone. Most of the attack surface is created by third-party components, which is why a site can run the newest WordPress core and remain exposed through an outdated plugin or theme.

For that extension layer, ScanTitan’s WordPress Plugin Vulnerability Statistics research tracks the concentration of disclosures in plugins, the growth in annual findings, patch status, severity, and exploitation speed rather than treating every WordPress finding as a core defect.

WooCommerce security statistics

WooCommerce illustrates why website-security research must distinguish a product from its ecosystem. A WooCommerce store inherits WordPress, WooCommerce core, payment extensions, checkout customizations, themes, analytics tools, and other plugins. A vulnerability in any one of those layers can expose the store without being a WooCommerce-core vulnerability. ScanTitan’s WooCommerce Vulnerability Statistics research separates core issues from extension and WordPress ecosystem risk so ecommerce exposure is not overstated.

Joomla security statistics

Joomla has a smaller installed base than WordPress but still combines core and third-party extension risk. In a selected mid-2026 mySites.guru research sample cited in ScanTitan’s Joomla research, 19 vulnerabilities were reported across 17 extensions, including nine file-upload or arbitrary-write issues and five unauthenticated SQL injection findings. That sample is not an ecosystem prevalence estimate; it is evidence that high-impact flaws can concentrate in extensions. ScanTitan’s Joomla Vulnerability Statistics page documents the sample and its limitations.

Ecommerce Website Security Statistics

Ecommerce security concentrates multiple high-value attack surfaces in one application: authentication, checkout, payment data, inventory, promotions, loyalty accounts, APIs, and third-party scripts. Imperva’s current retail and ecommerce telemetry reports that 41% of retail application traffic is made up of bad bots. Retail also accounted for 24% of business-logic abuse attacks and 20% of AI-bot attacks in its dataset, the highest share for those two categories. These are vendor-observed application and bot metrics, not percentages of retailers that were breached.

The threat is broader than bots. Web skimming campaigns show how a vulnerability can become payment fraud at the browser layer. Sansec’s CosmicSting investigation found 4,275 Adobe Commerce and Magento stores compromised after CVE-2024-34102 disclosure, approximately 5% of the Adobe Commerce/Magento population it monitored. Attackers used stolen cryptographic keys to generate privileged API tokens and inject payment skimmers into checkout pages. That incident connects vulnerability exploitation, API authorization, client-side code, and payment security in a single ecommerce attack chain.

WooCommerce has a different architecture but the same measurement problem: a compromised extension is not automatically a WooCommerce-core vulnerability. The CMS and plugin sections above therefore separate platform reach from extension risk rather than ranking ecommerce platforms by raw CVE totals.

Website Builder Security Statistics

Hosted website builders change who owns the security work. W3Techs’ September 2026 measurements put Shopify on 5.3% of all websites, Wix on 4.2%, and Squarespace on 2.5%. Those are adoption figures, not security ratings. A hosted platform generally centralizes core patching, infrastructure maintenance, TLS configuration, and many server controls with the vendor, reducing the amount of software maintenance an individual site owner performs.

That does not remove website risk; it moves it. Account takeover, compromised administrator credentials, unsafe custom code, third-party applications, malicious scripts, exposed APIs, DNS changes, and platform-wide vendor incidents remain possible. For that reason, a defensible comparison is not “website builders are secure while self-hosted CMSs are insecure.” It is “the responsibility boundary is different.” Self-hosted sites usually carry more direct patch and server responsibility, while hosted builders place more control in the vendor and make account, integration, and business-logic security comparatively more important.

API Security Is Now Part of Website Security

The boundary between a website and an API has largely disappeared. Modern ecommerce, SaaS, mobile backends, account portals, single-page applications, and headless CMS platforms expose business functions through APIs even when the user experiences them as a website. The 2026 Bad Bot Report found 27% of bot attacks targeted APIs, which matters because API endpoints often expose authentication, account actions, transactions, and data directly without requiring attackers to interact with a traditional page.

API risk is also difficult to inventory. Shadow endpoints, deprecated versions, undocumented routes, mobile APIs, and third-party integrations can remain reachable after the front-end interface changes. ScanTitan’s API Security Statistics research covers API-specific incident rates, attack growth, visibility gaps, and breach data so this page does not duplicate a separate attack-surface topic.

AI-Generated Website Security Statistics

AI-assisted development is now part of website security because models increasingly generate application code, routes, database access, authentication logic, and client-side components. Veracode’s Spring 2026 update tested more than 150 large language models using 80 coding tasks across Java, JavaScript, C#, and Python. Across the benchmark, only about 55% of generation tasks produced secure code when no security-specific guidance was given, meaning approximately 45% introduced a known vulnerability detected by Veracode’s static analysis.

The important denominator is generation tasks, not “45% of all AI-written production code.” Veracode’s benchmark tested four vulnerability classes: SQL injection, cross-site scripting, log injection, and insecure cryptographic algorithms. Syntax correctness exceeded 95%, while the security pass rate remained around 55%. That gap is useful for website teams because code that compiles, renders, or passes a functional test can still contain exploitable security defects.

For web applications, the highest-risk pattern is not AI itself but unreviewed security-sensitive output. Authentication checks, authorization rules, database queries, cryptography, API keys, secrets, cloud permissions, CORS rules, and input handling should be treated as security code regardless of whether a person or model wrote them. AI-generated websites therefore need the same code review, testing, dependency inventory, secret scanning, and runtime monitoring as conventionally developed applications.

Primary source: Veracode Spring 2026 GenAI Code Security Update.

Website Security Configuration Statistics

Configuration data provides one of the few ways to measure defensive posture directly across a large public sample. Report URI’s June 2026 crawl found 80.3% of 819,002 responding sites redirected to HTTPS. That means encryption in transit is now normal on the public web, but roughly one in five responding sites in that snapshot did not meet even that specific redirect measure. HTTPS is necessary, yet it should not be used as a proxy for overall website security.

Content Security Policy adoption shows a different maturity curve. Report URI observed 170,057 CSP policies, a dramatic increase from roughly 1,400 sites in 2016. However, 46.8% included unsafe-inline and 41.9% included unsafe-eval. Only 318 policies used require-trusted-types-for, representing about 0.2% of the CSP policies inspected. The numbers demonstrate a recurring security problem: deploying a control and deploying it effectively are different milestones.

Security headers are useful because they reduce classes of browser-side risk, but they do not patch server software. HSTS can prevent protocol downgrade, CSP can constrain script execution, and secure cookie attributes can reduce session exposure, yet none will fix an unauthenticated file-upload vulnerability or broken authorization check. Website security statistics should therefore measure both configuration and software risk rather than ranking sites by header score alone.

Website Malware and Infection Statistics

Malware datasets answer a different question from vulnerability databases: they show what was detected after compromise or suspicious modification. Sucuri’s 2024 SiteCheck analysis examined more than 1.1 million compromised websites and reported malware and malicious redirects together accounted for 74.7% of observed infections. Its remote scanner also found 169,163 websites loading resources from 575 known malicious domains during 2024. These figures come from Sucuri’s scanner population and should not be generalized into a percentage of all websites on the internet.

In the first half of 2024, Sucuri reported 681,182 infected sites in its SiteCheck data. Injected malware and redirects were detected on 473,135 sites, or 69.46% of infections in that six-month dataset, while SEO spam appeared on 234,033 sites. The same report identified 100,470 sites associated with Balada Injector detections. These numbers show how a compromised website can become infrastructure for redirect fraud, spam, malicious downloads, or further infection rather than simply displaying a defacement page.

Website Login and Credential Attack Statistics

Not every website compromise begins with a vulnerability. Credential stuffing, password reuse, stolen session tokens, phishing, infostealer logs, and automated login abuse can give attackers valid access without exploiting software. Imperva’s 2026 Bad Bot analysis reported that financial services accounted for 46% of account takeover incidents in its 2025 bot-activity dataset. The same report found that 27% of bot attacks targeted APIs, which matters because login, account recovery, loyalty, checkout, and profile actions are increasingly exposed through API endpoints.

Account-takeover statistics should not be converted into a universal percentage of website logins. They describe incidents observed in a particular security-provider population. The defensive implication is still clear: website security must protect identity as well as code. MFA for administrators, rate limiting, breached-password detection, session revocation, bot detection, anomaly monitoring, protected password-reset flows, and server-side authorization checks address risks that a vulnerability scanner alone cannot remove.

Retail telemetry reinforces the point. Imperva reports that bad bots make up 41% of retail application traffic, where automated abuse can target account creation, inventory, checkout, loyalty points, pricing, and credential testing. The security objective is to distinguish legitimate automation from malicious automation without blocking real customers or useful agents.

Third-Party Components and Software Supply-Chain Risk

Third-party code has become part of the website perimeter. A site can be fully patched at the server and CMS-core level while remaining exposed through a plugin, JavaScript dependency, tag manager, payment integration, analytics script, build pipeline, or compromised vendor. OWASP’s 2025 Top 10 formally expanded its old “Vulnerable and Outdated Components” category into Software Supply Chain Failures, reflecting the fact that risk now spans dependencies, build systems, distribution, and update channels rather than only known CVEs in installed packages.

Verizon’s 2026 DBIR adds an incident-level signal: third-party involvement reached 48% of breaches, up sharply from the prior period. That is an all-breach statistic rather than a website-only statistic, but it explains why web security teams need to inventory externally supplied components and services. The defensive task is not to eliminate third-party software; it is to know what is running, monitor advisories, remove abandoned components, restrict privileges, and update fast when exploitation evidence appears.

Website Security Risk for Small Businesses

Small organizations often operate the same public software and face the same automated traffic as larger firms, but with fewer people to monitor vulnerabilities and recover from incidents. In Verizon’s 2026 small-business dataset, exploitation of vulnerabilities was the leading initial access vector at 26%, ahead of credential abuse at 13% and phishing at 9%. Third-party involvement appeared in 55% of SMB breaches. Those are breach measures, not percentages of small-business websites.

The practical consequence is that a small-business website cannot rely on low visibility as a security strategy. Automated scanners and bots do not need to know how large a company is before testing an exposed plugin, login path, API route, or known CVE. ScanTitan’s Small Business Cybersecurity Statistics research covers the broader SMB breach, ransomware, identity, cost, and preparedness picture without turning all of those business-level statistics into website-specific claims.

Website and Web Application Attack Statistics by Industry

Industry comparisons are most useful when they come from the same telemetry source. Imperva’s current retail research reports that 41% of retail application traffic is bad-bot traffic, while retail receives 24% of business-logic abuse attacks and 20% of AI-bot attacks in its observed population. Financial services, meanwhile, accounted for 24% of all bot attacks and 46% of account takeover incidents in the 2026 Bad Bot Report. These percentages measure different attack categories and should not be added together.

Cloudflare’s 2025 DDoS data shows a different industry pattern. Telecommunications, service providers, and carriers were the most targeted industry for DDoS attacks overall and for the year’s hyper-volumetric campaigns; gaming and generative-AI service providers were also heavily targeted by very large attacks. This is why “most attacked industry” is not a universal ranking. Retail can lead business-logic abuse, financial services can lead account takeover in one dataset, and telecom can lead DDoS exposure in another because the attack type and denominator change.

For website owners, industry context should refine controls rather than replace asset-specific risk. Retail teams need stronger bot, checkout, loyalty, and inventory-abuse controls; financial services need stronger identity and account-takeover defenses; telecom and infrastructure providers need high-capacity availability protection. Every sector still needs software inventory, vulnerability remediation, logging, access control, and incident response.

Are Websites Becoming More or Less Secure?

The evidence supports both improvement and rising pressure. Websites are more likely to use HTTPS, CSP adoption is vastly higher than a decade ago, security standards have matured, and disclosure ecosystems are better at identifying flaws. At the same time, bots now generate the majority of traffic in Thales’ dataset, bad bots account for 40% of requests, WordPress ecosystem vulnerability disclosures rose 42% in 2025, and vulnerability exploitation became the leading breach entry point in Verizon’s 2026 DBIR.

Those findings are not contradictory because they measure different parts of the security lifecycle. A site can have HTTPS, HSTS, CSP, and modern authentication while still exposing a vulnerable extension. More disclosure can also be a sign of better research rather than declining software quality. The most defensible conclusion is that baseline defensive standards are improving, but the attack surface is expanding and attackers are automating faster. Security maturity therefore has to advance continuously rather than reach a one-time “secure” state.

Most Important Website Security Risks in 2026

The best current risk map is not a popularity list of attack names. OWASP Top 10:2025 emphasizes root causes and places Broken Access Control first, followed by Security Misconfiguration and Software Supply Chain Failures. Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures, and Mishandling of Exceptional Conditions complete the list. That ordering should guide application-security reviews, but individual websites still need asset-specific prioritization.

Website Security Statistics to Stop Citing

Some website-security claims are repeated so often that repetition is mistaken for verification. A research page should retire claims that cannot be traced to a current transparent methodology, especially when they appear precise enough to imply a global measurement system that does not exist.

Website Type vs Primary Security Exposure

Raw vulnerability counts are a poor way to compare website platforms because architectures assign security responsibility differently. A self-hosted CMS exposes patching and extension management directly to the site owner; a hosted builder centralizes more infrastructure with the vendor; ecommerce adds checkout and payment workflows; custom and AI-generated applications expose application logic and development mistakes. The table below compares responsibility and common exposure rather than pretending that one raw CVE count is a platform security score.

What the Data Means for Website Owners

The evidence points to a layered program rather than one security product. Websites need encrypted transport and browser hardening, but those controls sit beside software inventory, vulnerability remediation, identity protection, application testing, API visibility, malware monitoring, backups, and incident response. The highest-value change is to shorten the time between exposure and remediation because automated exploitation removes the luxury of waiting for a quarterly review.

Methodology and Sources

This research combines several source types because no single dataset measures the security of the entire web. Report URI supplies large-scale longitudinal website-configuration data from daily crawls of the Tranco top one million. Thales/Imperva supplies internet and bot-traffic telemetry plus large-scale web application attack measurements. Verizon DBIR supplies investigated incident and confirmed-breach data. Patchstack supplies WordPress ecosystem vulnerability disclosures. VulnCheck supplies evidence of real-world vulnerability exploitation. W3Techs supplies website technology and CMS market-share measurements. Sucuri supplies remote malware-scanner and compromised-site observations. OWASP supplies the current consensus risk taxonomy for web applications.

Every number is labeled according to its actual population. We do not convert a vendor customer sample into a percentage of all websites, describe attack requests as successful compromises, equate vulnerability disclosures with exploitation, or use an organizational breach-cost figure as the cost of a hacked website. Live market-share and vulnerability-database values are date-stamped because they can change. Where two sources measure different populations, both can be correct at the same time.

Primary sources used in this edition include the Report URI ten-year web security study, Imperva Cyber Threat Index, Imperva 2026 Bad Bot Report analysis, Verizon 2026 DBIR, Patchstack State of WordPress Security in 2026, VulnCheck 1H 2026 State of Exploitation, W3Techs CMS usage statistics, Sucuri SiteCheck Malware Trends Report 2024, the Cloudflare 2025 Q4 DDoS Threat Report, Veracode Spring 2026 GenAI Code Security Update, Sansec CosmicSting research, and OWASP Top 10:2025.

Frequently Asked Questions