Notes on API noise,
and the signal underneath.
Field notes on API abuse, anomaly detection, and building developer-first tooling deliberately. From the work behind APINine.
Four alerts, one attacker: correlating API alerts into an attack story
Reconnaissance, a probe of a dormant admin route, a burst of failed logins, then one successful login. Four alerts that look unrelated in a queue. Here's how to group them into one story using rules you can read.
Read →Microservices Broke the Security Perimeter. Most Teams Haven't Noticed.
The perimeter model assumed one front door. Microservices gave you dozens. Here's what that actually means for runtime security — and why the tooling most teams rely on was built for an architecture that no longer exists.
Read →Detection You Can Read: Why Explainable API Security Alerts Matter
Most API security tools answer 'is this an attack?' with a number you have to trust. The better question is whether the engineer on call can read the rule that fired — and disagree with it.
Read →What Makes an API Alert Worth Waking Up For
An alert that doesn't tell you how serious it is, or why it fired, isn't help — it's homework. Here's the case for detection you can read at 3am, not a score you have to trust.
Read →Why Most API Abuse Looks Valid at First
The dangerous API requests don't fail authentication. They pass it — and then do something they shouldn't. Here's why that's hard to catch, and what actually works.
Read →The dead-man's switch for telemetry
Most monitoring tells you when something fires. The more dangerous failure is when your telemetry goes quiet — and nothing tells you at all. Here's how APINine treats silence as a security event.
Read →Why valid traffic can still be dangerous
Most API attacks don't fail authentication — they authenticate successfully, then do something they shouldn't. Here's why that's the hard part.
Read →