API Security Statistics 2026: Attacks, Breaches & Data

Application programming interface (API) security statistics describe the fastest shifting attack surface in enterprise security, and they are easy to misread because incident rates, attack volume, and breach cost each measure something different. This page separates those measurements, sources each to its primary publisher, and explains the central finding of 2026: multiple independent datasets now describe APIs as the primary enterprise attack surface, ahead of both web applications and network infrastructure, with attack volume rising faster than most organizations can inventory the endpoints they expose.

Last updated: August 2026. This page is a source audit, reviewed quarterly. You are welcome to cite it with a link back to ScanTitan.

Key API security statistics at a glance

Each row states the figure, what it actually measures, the year of the underlying data, and the source, so an editor can quote it without misreading it.

What these numbers actually measure

API security statistics get misused when incident surveys, attack telemetry, and breach analysis are treated as one thing. Four distinctions carry most of the risk.

Why APIs are the primary attack surface in 2026

Multiple independent datasets converged on the same conclusion this year. Akamai’s 2026 research found that 87% of organizations experienced an API related security incident in 2025, and that the average number of API attacks per organization rose from 121 to 258 per day, a 113% year over year increase. Akamai’s security leadership now describes APIs as the primary attack surface for the modern enterprise, ahead of both web applications and network infrastructure. Application layer distributed denial of service (Layer 7 DDoS) attacks grew 104% over two years in the same telemetry.

The convergence is what makes the finding credible rather than a single vendor’s claim. Wallarm’s 2026 API ThreatStats analysis reported that APIs now account for 43% of CISA’s actively exploited vulnerabilities, tying the API surface directly to confirmed exploitation rather than survey sentiment. Salt Security’s research found that 99% of organizations encountered an API security problem in the past 12 months.

API attacks over time

The API attack surface did not appear suddenly; it grew into the primary position over several years of measurement. Akamai’s earlier State of the Internet research found that 29% of all web attacks targeted APIs across 2023, with commerce the most attacked vertical at 44% of API attacks. By 2025, Akamai’s telemetry showed the average number of API attacks per organization rising to 258 per day, up from 121, a 113% year over year increase, alongside a 104% rise in application layer distributed denial of service attacks over two years. The trajectory is the point: API attacks moved from a notable share of web attacks to the leading enterprise attack surface in roughly three years, which is why treating the API surface as an afterthought no longer matches the data.

API attack growth and the visibility gap

The core problem is that API growth is outpacing the ability to see and secure it. Salt Security found that 66% of organizations reported their API count grew by more than 50% in the last year, an expansion driven by microservices and, increasingly, by artificial intelligence (AI). The visibility side has moved in the opposite direction. Akamai reported that while 77% of respondents claim a full inventory of their APIs, the share that knows which APIs return sensitive data has fallen for four consecutive years, from 40% in 2022 to just 23% in 2026.

That gap has a name in the industry: shadow and zombie APIs. Shadow APIs are undocumented endpoints deployed without security team knowledge, and zombie APIs are deprecated endpoints that remain live. The table below summarizes the growth and visibility figures side by side, because the risk lives in the distance between them.

Where AI compounds API risk

Artificial intelligence has become a force multiplier on both sides of the API attack surface. Akamai found that 42% of security professionals who reported API linked incidents said those incidents involved APIs connected to AI technologies such as applications, agents, and large language models. The mechanism is direct: AI linked APIs determine what data a model can access and what actions it can trigger, so when an attacker manipulates an AI through techniques like prompt injection, it is the underlying API that fetches the sensitive data or performs the action.

The build side compounds the problem. As organizations rush to connect systems to language models, they create thousands of new endpoints faster than governance can track them, and AI generated API code can introduce security gaps that automated review misses. Wallarm reported that AI related vulnerabilities grew sharply year over year, with a meaningful share involving APIs. The practical consequence is that the API inventory and the AI inventory are now the same problem, and neither can be secured without visibility into the other.

The most common API vulnerabilities

Attackers concentrate on a small set of predictable flaw classes, which makes prioritization possible. The OWASP API Security Top 10 lists Broken Object Level Authorization (BOLA) as the number one risk, followed by Broken Authentication and Broken Object Property Level Authorization. These are authorization and authentication failures rather than exotic exploits, which means access control review returns more security per hour than chasing rare bugs. Wallarm’s analysis of API breaches found that broken authentication alone caused 52% of the incidents it examined, reinforcing the same point from breach data rather than a framework.

The reason these flaws dominate is structural. An API is designed to be called programmatically, so a weak or missing authorization check is directly reachable by an attacker with no user interface to slow them down. That is also why API directed attacks now make up a large share of automated traffic: in Imperva’s bot data, more than a quarter of bot attacks targeted APIs. A public API is exposed by definition, so the same discipline that protects a website, continuous discovery and scanning, applies to the API surface. An API vulnerability scanner is built to test that surface against these authorization and authentication failure classes.

Understanding the OWASP API risk classes

The OWASP API Security Top 10 exists because API risk concentrates in a few authorization and authentication failures rather than spreading evenly. Broken Object Level Authorization, the number one entry, occurs when an API returns a record without checking that the caller is allowed to see that specific object, which lets an attacker change an identifier in a request and read someone else’s data. Broken Authentication, the second entry, covers weak or missing verification of who is calling, including flawed token handling. Broken Object Property Level Authorization covers exposing or accepting fields a caller should not touch. These are logic and access control failures, not memory corruption or exotic exploitation, which is why they are both common and preventable. The practical implication is that API defense is mostly authorization review, confirming on every endpoint that the caller is allowed to perform the action and see the data returned. Wallarm’s breach analysis, which attributed 52% of examined API breach incidents to broken authentication, draws the same lesson from real incidents rather than a framework.

The cost and impact of API incidents

The financial picture rose alongside the attack volume. Akamai’s API Security Impact Study, a survey of 1,840 security leaders and practitioners across 10 countries and 6 industries, put the average cost of an API incident above 700,000 dollars, and reported that API related breaches cost top quartile organizations upward of 1.8 million dollars annually. Cost varied sharply by sector: the study found the costliest incidents in energy and utilities, followed by manufacturing and health and life sciences.

Salt Security’s research adds the operational cost that does not appear on a breach invoice. It found that a large share of organizations slowed the rollout of a new application because of API security concerns, which means the API risk gap also acts as a brake on the business. The combined picture is that API incidents are both more frequent and more expensive than they were, while the growth of the surface makes each one harder to prevent, a pattern that argues for building security into the API lifecycle rather than bolting it on afterward.

API incident cost by sector

Cost is not uniform across industries, and the sector breakdown helps a security team benchmark realistically. Akamai’s API Security Impact Study reported the costliest API incidents in energy and utilities, at an average around 860,000 dollars, followed by manufacturing at about 732,000 dollars and health and life sciences at about 725,000 dollars. These sit above the overall average incident cost of more than 700,000 dollars, and well below the top quartile annual figure of upward of 1.8 million dollars for API related breaches. All of these are survey figures from the same study of 1,840 security professionals, so they share a population and should be read as survey averages rather than measured losses for any single organization.

API breaches in context

Named API breaches illustrate why the flaw classes above matter, though individual incidents should be read as examples rather than statistics. Large breaches attributed to API weaknesses have exposed data at very large scale across recent years, and the common thread in public post mortems is authorization and authentication failure rather than novel exploitation. The lesson is not that any single breach defines the trend, but that the same root causes recur: an endpoint that returned more data than it should, or that failed to verify who was asking. Reported figures for individual API breaches routinely reach into the millions of affected records, and the pattern across public disclosures is consistent, with the failure almost always in authorization or authentication rather than in a novel exploit. That consistency is the useful signal for defenders, because it means the same small set of controls, verifying identity and checking object level authorization on every call, would have prevented most of them.

For the broader vulnerability and exploitation picture that surrounds these API specific figures, including how quickly disclosed flaws are exploited, see our vulnerability statistics page. APIs are one high growth slice of that larger exploitation surface, and Wallarm’s finding that they now represent 43% of actively exploited vulnerabilities is the clearest single link between the two.

Statistics to stop citing

Honest API security statistics means being careful with numbers that get stretched beyond what they measure.

Source-lineage verification table

How to reduce API risk

The data points to a discovery first, authorization focused checklist rather than a generic control set.

Methodology and sources

This page is a source audit of API security statistics, built on a few principles: it prioritizes primary vendor research and links it where possible; it labels survey self report separately from measured telemetry; it keeps incident rates, attack volume, exploited-vulnerability shares, and breach cost as separate measures; it marks the population and sample of survey figures; and it refuses to repeat a claim it cannot attribute to a named publisher. Primary and named sources include Akamai’s 2026 State of the Internet report and API Security Impact Study, Salt Security’s State of API Security research, Wallarm’s 2026 API ThreatStats analysis, the OWASP API Security Top 10, and Imperva bot traffic data. This page is reviewed quarterly. You are welcome to cite it with a link back to ScanTitan.

Frequently asked questions