Almost every modern application is really a collection of APIs talking to each other. Your login flow is an API. Your checkout is an API. The mobile app that feels native is a thin shell over a dozen API calls. Somewhere along the way the API stopped being plumbing and became the product, and the data behind it became the thing attackers want most.
The defences, for the most part, did not keep up. Many teams still rely on a web application firewall tuned for the threats of a decade ago, looking for known bad strings at the network edge. That catches the noisy, generic attacks. It misses the quiet ones that look exactly like a normal request.
The attacks that look like traffic
The most damaging API attacks are not exotic payloads. They are ordinary-looking requests used in a way the designer never intended.
- Broken object level authorisation. Change one identifier in a request and read another customer's record. Nothing about the request is malformed. The logic simply failed to check who is asking.
- Business logic abuse. Enumerating a checkout, stacking coupons, draining inventory. Each call is valid on its own. The abuse only shows up in the pattern.
- Account takeover. Credential stuffing and enumeration that ride legitimate endpoints at machine speed.
A signature cannot describe any of these, because there is no signature. The request is well formed. What is wrong is the intent and the behaviour, and you can only see that by understanding what normal looks like first.
If your tooling cannot tell the difference between a customer and an attacker who sends the same well formed request, it is not really watching your API.
Why this keeps getting worse
Three trends compound the problem. APIs multiply faster than anyone documents them, so shadow and forgotten endpoints pile up. Protocols diversify beyond REST into WebSocket and gRPC, where many tools simply do not look. And breach economics keep rewarding the attacker. In IBM's 2026 study, the average breach cost USD 4.99 million. Exploited vulnerabilities were the most common way in, at 31% of breaches, according to Verizon.
What good looks like now
Effective API security in 2026 has a recognisable shape:
- It learns behaviour, not just signatures. A baseline of normal makes the abnormal visible.
- It sees every protocol. REST, WebSocket, gRPC and streaming protocols, not just the easy ones.
- It stays out of the live path. Security that can take down production is its own risk. Watching out of band removes that failure mode.
- It explains itself. A finding a human cannot understand and act on is just more noise.
This is the gap we built Cyron API Security to fill. It runs at the Linux kernel with eBPF, copies traffic out of band across REST, WebSocket, gRPC and streaming protocols, and adds nothing to the request path.
Where to start
You do not need a six-month programme to make progress. Get an honest inventory of your endpoints, including the ones nobody remembers. Establish what normal behaviour looks like for the sensitive ones. Then put detection on the abuse classes that signatures miss. The teams that do this stop reading about breaches and start catching the precursors instead.
Sources
- OWASP API Security Top 10 (2023), OWASP
- IBM study: one in four malicious breaches are AI-enabled (Cost of a Data Breach 2026), IBM Newsroom, 29 July 2026
- 2026 Data Breach Investigations Report, Verizon
Updated 1 October 2026: protocol coverage, breach figures, author and sources added.