Detection: Anomalies, Abuse and Credential Stuffing

Every control covered so far in this course — strong authentication, correct authorization, input validation, rate limiting — is a control your API enforces on a single request at a time. Credential stuffing doesn't break any single one of them: an attacker trying a leaked username-and-password pair against your login endpoint is sending a completely well-formed, correctly-structured authentication request. It fails authentication like any wrong password does, which is exactly the problem — nothing about that one request looks different from a legitimate user simply mistyping their password, and an attacker with millions of leaked credential pairs from an unrelated breach only needs a small fraction to work against your specific service to succeed at scale.

This is why detection is a genuinely separate discipline from the per-request controls covered earlier: it operates on patterns across many requests over time — this IP tried 40,000 different username/password combinations in an hour, this account was accessed from three countries in ten minutes, this API key's call volume just increased twenty-fold overnight — rather than judging any single request in isolation. A request-level control can't see a pattern; only something watching the aggregate can, which means detection lives architecturally downstream of and alongside your other controls, not instead of them.

Analogy🏏Cricket

🏏 Think of it like cricket: A single delivery in a match, watched in isolation, rarely tells you anything is wrong — a batter playing and missing, a bowler sending down a wide, a fielder misjudging a catch, each individually looks like the ordinary texture of the game. What actually flags a match-fixing concern to an anti-corruption unit is a pattern across many deliveries and many overs: an unusual cluster of wides at a specific score, or betting-market activity spiking around a specific, pre-arranged passage of play that doesn't correlate with anything happening on the field. No single ball is the evidence; the pattern across the innings is. Just as no single delivery reveals a fixing pattern, no single login attempt with a wrong password reveals a credential-stuffing attack — it looks identical to an ordinary mistake. Just as an anti-corruption unit watches betting patterns and delivery sequences across an entire match rather than reviewing balls one at a time for suspicion, an API's abuse-detection system watches request volume, geography, and timing patterns across many requests rather than judging any single request for maliciousness. The insight is that some categories of attack are only visible in aggregate, which means the defence has to operate at the aggregate level too — a control built to judge one request at a time will never see them.