The short version. The breaches that hurt most are rarely exotic. They are an ordinary request, perfectly well-formed, asking for an object that belongs to someone else. Your web application firewall waves it through, because there is nothing malicious in the payload. The problem is not that the WAF is weak. The problem is that a signature firewall was never designed to know that user A is not allowed to read user B's invoice. That knowledge lives in your application, and only a defense that has learned your application can enforce it.
The number one API risk is boring, and that is why it wins
Look at the OWASP API Security Top 10 and the item at the top is Broken Object Level Authorization, BOLA. In plain terms: the app lets a user access an object they should not, usually by changing an ID. GET /api/invoices/1001 returns your invoice. Change it to 1002 and you get someone else's, because the app checked that you were logged in but forgot to check that this particular invoice was yours.
There is nothing to detect in that request. It is well-formed. It has no injection, no malicious string, no anomaly a pattern-matcher would flag. It is a legitimate-looking request for an illegitimate object. This is business-logic abuse, and it is the category behind a large share of real API breaches, precisely because it hides in traffic that looks completely normal.
Your signature WAF cannot see it. Not because it is a bad WAF, but because it does not know your business rules. It knows what a SQL injection looks like in the abstract. It does not know that invoice 1002 belongs to a different tenant. That fact is not in any signature. It is in your application's logic and your data.
Why signature defenses are structurally blind here
A traditional WAF works from a global negative model: a library of known-bad patterns, the same for every customer. That model has two failure modes that pull in opposite directions.
It blocks too much that is fine. Because the patterns are generic, they flag legitimate traffic that happens to resemble an attack, and your team spends its week writing exceptions. This is the false-positive tax that makes people turn WAFs down to "log only."
And it misses the attacks that are specific to you. Business-logic abuse, BOLA, mass assignment, abnormal call sequences, none of these match a generic bad-pattern, because they are only bad in the context of your app. A global model cannot encode "this sequence is normal for a checkout but abnormal for a refund," because it does not know your checkout or your refund.
The deeper issue is the direction of the model. A negative model asks "does this look like a known attack?" The attacks that hurt you do not look like known attacks. They look like your own traffic, slightly wrong.
Turn the model around: learn what is normal for you
The alternative is a positive security model. Instead of enumerating infinite bad, you learn finite good: what your application actually does, and treat deviations from that as suspect.
Concretely, that means learning a per-tenant envelope of behavior:
- The request shape. Which endpoints exist, what parameters they take, what types and ranges are legitimate. A parameter that has only ever been a small integer suddenly carrying a path is a deviation.
- Object access patterns. Whether a user is reaching for objects consistent with their prior behavior, or walking IDs across a tenant boundary. BOLA is a deviation in access, and access is learnable.
- Response shape. What a normal response looks like, so a request that suddenly returns ten thousand records where one is normal is visible as exfiltration, even when the request itself looked fine.
- Sequence. The order of calls that real workflows produce, so a step performed out of order, or a state machine skipped, stands out.
An attack becomes a deviation from your application's own normal, not a match against someone's generic pattern list. This catches the boring, dangerous attacks a signature engine cannot: the well-formed request for the wrong object, the workflow performed in the wrong order, the response that leaks more than it should.
The critical design detail is per-tenant. Many products learn a global model across all their customers, which sounds efficient and is quietly wrong, because your normal is not the industry average. Your app has its own legitimate weirdness. A model learned from everyone treats your normal as an anomaly and hands you back the false-positive problem you were trying to escape. The baseline has to be yours.
How Nemesis Shield approaches it
Nemesis Shield's application engine learns a per-tenant behavioral baseline of your app and API: endpoint and parameter shapes, access patterns, response shapes, and call sequences, and then flags and blocks the deviations a signature WAF cannot see. It installs in one line and never reads your source code. What the SDK sends is a structural sketch, the shape of a request and response, hashed on the device, never the raw payload or the customer data inside it. It learns the shape of your traffic without seeing its contents.
Two things keep it deployable where WAFs and RASP stalled. Enforcement is staged, observe, then alert, then enforce, and gated on readiness, with a shadow mode that shows you what it would have blocked before it blocks anything. And every block ships with its evidence, the learned-versus-observed diff, so a developer can see in seconds why a request was stopped and approve it with one click if it was legitimate.
We are straight about the boundary. A positive model catches deviations. It does not catch abuse that stays entirely inside your learned envelope, a logic attack that uses only normal-looking calls in a normal-looking order. That is a genuine gap, it is narrow, and we would rather name it than imply we block everything. Behavioral defense is a strong layer, not a force field.
What to check when the boring attack is the real threat
- Ask your current WAF one question: can it stop user A from reading user B's object when the request is otherwise valid? If not, that risk is unaddressed today.
- Positive or negative model? Does the tool learn your normal, or match generic bad?
- Per-tenant or global baseline? A global model reintroduces the false positives you are trying to escape.
- Does it read your code or your data? A defense that only needs the shape of traffic is one you can actually turn on.
- What does it admit it misses? In-envelope logic abuse is the honest gap. A vendor who claims none is not measuring.
The attacks that end up in the breach notification are usually the plain ones: a valid request for an object that was never yours. You cannot pattern-match your way to catching those. You have to know what your application's normal looks like, and notice when a request is a little bit wrong.
Nemesis Shield's application engine learns a per-tenant positive-security baseline for your apps and APIs, then blocks the deviations a signature WAF misses, with proof on every block. In early access. nemesislabs.xyz/shield