Apartment buildings have a door. Visitors who belong ring a specific apartment. Visitors who do not belong are supposed to wait downstairs until someone buzzes them in. The system breaks when a stranger runs their finger across every button, hoping one tenant will open the door out of reflex. Security researchers call this broken authentication. The same pattern—exploiting a system's trust in automated input—is now playing out at scale across the internet's API infrastructure.
A newly circulated industry report puts numbers to what security teams already feel. API authentication attacks climbed 681% over the past year, while overall API traffic grew a more modest 321%. In the same period, 95% of surveyed organizations reported at least one API security incident, and 34% admitted they still lack a formal API security strategy. The math is uncomfortable: attackers are following the traffic, but they are outpacing it by a wide margin.
The short version
- API authentication attacks rose 681% year over year, against 321% growth in overall API traffic.
- 95% of surveyed organizations reported at least one API security incident in the past 12 months.
- 34% of those respondents admitted they still have no API security strategy in place.
- 62% said they have delayed application launches because of API security concerns.
- 83% are not confident their organization even has a complete inventory of its APIs.
How bad is the defender side, really?
The most uncomfortable data point is the inventory gap. If 83% of respondents are not confident they know how many APIs they have, the rest of the conversation about patching, rate limits, and WAF rules is partly theoretical. You cannot defend an asset you cannot name.
That gap creates two failure modes that are now competing in organizations. One is shipping a vulnerable API quickly because business pressure overrides security caution. The other is freezing a feature while security catches up. Neither is clean, and the fact that 34% of organizations openly admit to having no strategy suggests the freeze is rare.
High-traffic APIs see so many legitimate authentication events that a small trickle of credential-stuffing attempts can look like noise. Without baseline-aware detection, the attack blends in.
Our analysis
The 681% figure deserves scrutiny. It counts attack events, not successful breaches, and it sits alongside a 321% rise in legitimate API traffic. Part of that growth is attackers following the data. APIs are where the data is, and data is the prize.
The more revealing number is the 34% with no strategy at all. That is not an infrastructure problem—it is an organizational one. Most teams know what they should be doing. The gap is execution, not awareness.
The asymmetry favors attackers. An adversary needs one unguarded endpoint, a list of credentials, and patience. A defender needs an inventory, per-endpoint rate limits, anomaly detection, key rotation, and developer discipline across every team shipping code. The cost curve slopes toward the attacker, and the report reflects that.
The trade-off is uncomfortable by design. Heavy rate limits and aggressive anomaly blocking protect the endpoint but can break partner integrations and frustrate mobile users. Loose limits keep the business moving but let credential-stuffing through. There is no setting that satisfies both sides. The honest path is to choose a position, measure the outcome, and adjust.
One thing to watch: machine-learning-based bot detection is changing the cost math. It forces attackers to either slow down dramatically or invest in behavior emulation. Either option narrows their margin.
Who should care
Developers shipping APIs** — You own the interface attackers probe first. Understanding credential stuffing, brute-force patterns, and enumeration is not optional anymore.
Security teams with no strategy** — The 34% figure means your peers are in the same boat. Inventory and rate limits are places to start that do not require new tooling.
Product managers weighing speed versus safety** — The 62% who delayed launches are absorbing real business cost. The question is whether that cost is higher than the alternative.
Practical steps
- Pull a current API inventory from your gateway logs, cloud account, and developers. Compare the three lists. The gaps are your blind spots.
- Put per-endpoint rate limits in front of every authentication route, tuned to normal user behavior rather than total traffic volume.
- Move from shared API keys to short-lived tokens, and rotate long-lived keys on a schedule customers cannot ignore.
- Subscribe to a credential-stuffing feed and block known-bad passwords at the authentication layer, not the application layer.
Bottom line
API authentication attacks are not a new technique aimed at a new surface. They are an old, cheap, effective technique that found a growing target. The data points to a defender community that is aware of the risk, struggling to inventory its own assets, and slow to standardize. The work ahead is unglamorous: count your APIs, throttle the door, and stop treating passwords as sufficient protection.
Frequently asked questions
What is an API authentication attack?
Any attack targeting the login or token-issuing endpoint of an API, most commonly credential stuffing, brute-force guessing, or username enumeration.
Why are APIs more exposed than regular web logins?
APIs often have higher traffic, looser rate limits, and less behavioral monitoring than human-facing login pages, which makes automated abuse harder to spot.
Do these attacks actually succeed?
The report says 95% of surveyed organizations suffered an API security incident in the past year, though it does not break down which types were responsible.
What is the single most useful first step for a security team?
Build a complete inventory of every public-facing API. Most teams cannot reliably list theirs, and that gap blocks every other control.
Are password managers and unique passwords still recommended?
Yes. Unique, randomly generated passwords limit the value of any single credential dump and reduce the blast radius of a stuffing attack.