Chapter 40D — WAAP: bots, API discovery, and edge enforcement

Worked example

The exposed test API that nobody was watching — the API9:2023 pattern, at real scale.

   In 2022, a large Australian telecommunications provider (Optus)
   experienced a breach affecting roughly 10 million current and former
   customers' records (names, dates of birth, addresses, phone/passport/
   driver's-licence numbers in various combinations depending on the
   record). Widely reported details of the incident describe an
   internet-reachable API that required NO AUTHENTICATION to query
   customer records at scale -- an API that, by its exposure and lack of
   basic access control, was clearly not being tracked, monitored, or
   protected the way the organisation's OTHER, better-known customer-
   facing APIs presumably were.

   THIS IS THE TEXTBOOK "SHADOW API" FAILURE MODE: an endpoint that
   exists, is reachable, and does real damage when abused -- but isn't in
   anyone's inventory, isn't covered by the WAF's tuned rule set (because
   nobody configured rules for an API they didn't know was live), and
   isn't rate-limited or authenticated the way a properly-tracked,
   security-reviewed endpoint would be.

   WHAT A WAAP'S API-DISCOVERY CAPABILITY SPECIFICALLY ADDRESSES:
     - passive traffic observation would have SURFACED this endpoint as
       "receiving real production traffic" regardless of whether it was
       in anyone's documentation.
     - a policy of "every discovered endpoint must be explicitly
       reviewed, classified, and either brought into the authentication/
       rate-limiting baseline or decommissioned" turns "we didn't know it
       existed" from a plausible excuse into an actively-caught finding.
     - this is precisely Part 7 Ch 41's data-classification-and-inventory
       discipline, applied to the API SURFACE ITSELF rather than to data
       stores -- and it's why API9:2023 exists as its own numbered item in
       the OWASP API Security Top 10 (Ch 40E) rather than being folded
       into general misconfiguration.

   THE FIX PATTERN: continuous API discovery (WAAP platform, or a
   self-built traffic-observation pipeline feeding your Part 8 telemetry
   stack) + a hard policy that NO endpoint goes live without being in the
   inventory + a scheduled audit comparing "endpoints receiving traffic"
   against "endpoints in the documented, security-reviewed inventory,"
   with any drift treated as a P1 finding (Ch 59), not a documentation
   backlog item.

Real-world scenario 2: automated abuse of a legitimate, under-throttled feature

   In April 2021, a dataset covering roughly 533 million Facebook
   accounts -- phone numbers linked to names, locations, and other
   profile fields -- surfaced publicly, compiled from data scraped years
   earlier. Facebook's own public statements traced the underlying
   technique to a CONTACT-IMPORTER / "Find Friends"-style feature: a
   perfectly legitimate capability (helping a real user find contacts
   already on the platform by matching phone numbers) that had
   insufficient throttling and bot detection on how many lookups a
   single automated actor could perform. Attackers ran large-scale,
   automated queries through this legitimate feature -- not by
   exploiting a coding bug in the classic sense, but by using the
   feature exactly as designed, at a volume and automation level no real
   user would ever generate. Facebook stated the underlying issue had
   been addressed by 2019, but the previously-harvested data continued
   to circulate and resurface afterward.

   WHY THIS IS A WAAP CHAPTER EXAMPLE, NOT A WAF ONE: every individual
   request in this pattern was SYNTACTICALLY PERFECT -- a well-formed
   call to a legitimate, intentionally-public API, with a valid phone
   number and no injection payload anywhere in sight. Nothing about ANY
   SINGLE request matches a WAF signature. What's anomalous is the
   AGGREGATE PATTERN: an enormous request volume from automated,
   non-human clients systematically working through phone-number space
   -- precisely the shape of abuse this chapter's BOT MANAGEMENT layer
   (fingerprinting non-browser clients, behavioural analysis, and
   escalating challenges as volume grows from a single fingerprint or
   fingerprint cluster) exists to catch, and precisely the shape of
   abuse Ch 40B's basic per-IP/per-key rate limiting alone is generally
   too coarse to stop at this scale without also incorporating bot-
   classification signals.

Real-world scenario 3: credential stuffing against consumer apps

   Two separate, publicly documented incidents illustrate the SAME
   underlying pattern at consumer scale: Dunkin' Donuts disclosed (and
   was later the subject of a 2020 New York Attorney General
   settlement, following an earlier 2015 incident) that attackers used
   CREDENTIAL STUFFING -- automated login attempts using username/
   password pairs stolen from OTHER, unrelated breaches -- to take over
   customer loyalty accounts and drain stored gift-card balances.
   Chick-fil-A separately disclosed in 2019 that mobile-app accounts
   were compromised through the same technique, again enabling
   fraudulent use of stored payment/loyalty balances.

   IN BOTH CASES, THE LOGIN REQUESTS THEMSELVES WERE UNREMARKABLE: a
   correctly-formatted username and password submitted to a legitimate
   login endpoint. There is no payload for a WAF signature to match and,
   often, no SINGLE account's login attempts exceeded a naive per-
   account rate limit (Ch 40B) if the attacker tried each stolen
   credential pair only once or twice per account before moving on to
   the next. What made the traffic recognisable as an attack was:
     - the SOURCE pattern: a volume and velocity of LOGIN ATTEMPTS
       across a huge number of DIFFERENT accounts, consistent with an
       automated credential-stuffing tool rather than real users typing
       passwords (bot fingerprinting and behavioural analysis, this
       chapter).
     - the SUCCESS-RATE signature of credential stuffing specifically:
       a low but non-zero hit rate against a large batch of attempted
       username/password pairs, because SOME fraction of any large
       stolen-credential list is reused by real account holders on the
       targeted site (a detectable pattern -- an unusually high volume
       of DISTINCT-username login attempts from related bot
       infrastructure, most failing, a small percentage succeeding --
       very different from a real user's behaviour and from a targeted
       brute force against ONE account).
   Rate limiting alone (Ch 40B) reduces the RATE of an attack like this;
   it doesn't recognise the ATTACK PATTERN itself. Bot management --
   this chapter's actual answer to credential stuffing -- is what
   distinguishes "many different real users logging in slowly" from
   "one automated tool trying many stolen credential pairs slowly,
   specifically to stay under a naive rate limit."