Chapter 40E — Implementing the OWASP API Security Top 10 (2023)

Worked example

Running the full Top 10 as a design-review checklist against a real feature.

   FEATURE: SecureShop adds a "price-match" feature -- customers submit a
   competitor's product URL; the backend fetches that page, extracts a
   price via a third-party price-comparison API, and auto-applies a
   discount if the competitor's price is lower.

   WALKING THE LIST:
     API1 BOLA        -- does GET /price-match/{id} check the requester
       OWNS that price-match request? (Yes/no per Part 5 Ch 25 -- verify.)
     API2 Auth        -- is this endpoint behind the same session/token
       validation as checkout? (Confirm, don't assume "it's just a
       lookup so it's lower risk.")
     API3 Property    -- does the response leak the INTERNAL competitor-
       API's raw response (which might include the competitor's own
       internal identifiers or unrelated fields)? Shape the response to
       exactly the fields the customer needs.
     API4 Resource     -- is there a limit on how many price-match
       requests one account can submit per hour? (Ch 40B business-flow
       limiting -- otherwise this becomes a free, unlimited web-scraping
       proxy for anyone with a SecureShop account.)
     API5 Function     -- can a non-staff account somehow reach an
       internal "force-apply any discount" variant of this endpoint?
     API6 Business flow -- could a bot submit thousands of price-match
       requests to systematically discover pricing/discount logic, or to
       abuse the discount mechanism itself at scale? THIS is exactly the
       new-in-2023 item this feature is most exposed to.
     API7 SSRF         -- the feature FETCHES A USER-SUPPLIED URL. This
       is a textbook Part 6 Ch 33 SSRF surface -- allowlist, resolve-
       validate-pin, no internal targets, no redirects.
     API8 Misconfig    -- is the third-party price-comparison API's
       credential stored per Part 7's secrets discipline, not hardcoded?
     API9 Inventory    -- is this new endpoint added to the OpenAPI spec
       and the WAAP's known-endpoint baseline on day one, not discovered
       three months later as traffic drift?
     API10 Unsafe
     consumption       -- the THIRD-PARTY PRICE API'S RESPONSE is
       rendered to the customer (the competitor's price, maybe a product
       title). Is that response OUTPUT-ENCODED before display? Is its
       JSON schema-validated before being used in a discount calculation
       (a malformed or adversarially-crafted response could otherwise
       manipulate the discount logic itself)?

   RESULT: two items (API7's SSRF surface, from fetching a user-supplied
   URL, and API6's business-flow abuse potential) are the standout risks
   for THIS specific feature, and API10 (trusting the price API's
   response) is the one a typical review would have skipped entirely.
   All ten get a concrete answer, not a shrug -- and the review took
   twenty minutes because every control already exists somewhere in this
   guide; the checklist's job was just making sure someone asked.

Real-world scenario 2: API1, in the clearest possible form

   Brian Krebs reported in November 2018 that the United States Postal
   Service's "Informed Visibility" API -- a legitimate service letting
   businesses track their mail -- contained an authentication flaw that
   let ANY authenticated user, even one with the lowest available
   account privilege, query data belonging to OTHER users' accounts
   simply by supplying a different account identifier in the request.
   USPS confirmed and fixed the issue after being contacted; the
   exposure reportedly affected data on roughly 60 million user
   accounts (account details such as email, username, user ID, account
   number, street address, phone number, and more, depending on the
   query).

   THIS IS API1:2023 (BROKEN OBJECT LEVEL AUTHORIZATION) IN ITS PUREST
   FORM: the API correctly checked that the caller WAS authenticated
   (API2 was fine), but never checked that the OBJECT being requested
   (another user's account record) actually BELONGED to the caller
   making the request. There was no clever bypass, no encoding trick, no
   injection -- just a missing `WHERE owner_id = :caller_id` (G1 Ch 45's
   original framing of this exact bug class) at API scale. It is worth
   sitting with how SIMPLE the root cause was, and how LARGE the blast
   radius became purely because of scale and because nobody had applied
   Ch 40E's ten-item pass -- API1 specifically -- to this endpoint before
   it shipped.

Real-world scenario 3: API2 and API4 together, at large scale and recent

   T-Mobile disclosed in a January 2023 regulatory filing that a
   malicious actor had used a SINGLE API to obtain data associated with
   approximately 37 million current customer accounts, with the
   unauthorised activity beginning around late November 2022 and
   identified/stopped in early January 2023. T-Mobile's own filing
   described the data obtained as including customer name, billing
   address, email, phone number, date of birth, account number, and
   service-plan details -- not payment card or Social Security numbers
   or passwords in this particular incident, per the company's
   disclosure.

   MAPPED TO THIS CHAPTER'S CHECKLIST, TWO ITEMS COMPOUNDED:
     API2 BROKEN AUTHENTICATION   the API's access controls were
       insufficient to prevent this scale of unauthorised querying in
       the first place -- exactly the "weak token validation / missing
       checks on a sensitive flow" shape of API2.
     API4 UNRESTRICTED RESOURCE CONSUMPTION   even setting authentication
       aside, an API that permits ONE caller to pull data on 37 MILLION
       distinct accounts over roughly five weeks reflects an absence of
       the volume-based limits Ch 40B exists to enforce -- a properly
       rate-limited and volume-monitored API (Part 8's DAM/UEBA-style
       baselining, applied at the API-gateway layer) should have flagged
       an anomalous, sustained, large-scale extraction pattern from a
       single caller LONG before it reached tens of millions of records,
       independent of whatever authentication weakness let the querying
       begin at all.

   THE COMPOUND LESSON: this is why Ch 40E's checklist is walked
   ITEM BY ITEM rather than stopping at the first thing found. A review
   that caught and "fixed" only the authentication gap (API2) but never
   asked "and is there ALSO a volume/consumption limit on this data,
   regardless of who's asking" (API4) would have left exactly the
   control that could have caught this incident early, or slowed it to a
   trickle, sitting unbuilt.