Worked example

Mass assignment through a payload gate that validated presence but not shape — and the fix.

   SecureShop's `PATCH /api/users/me` endpoint validates that the JSON
   body is well-formed and that `name` and `bio` are strings -- but the
   schema has no `additionalProperties: false`, so it silently accepts
   (and an underdocumented internal helper blindly merges) whatever else
   is in the body.

   ATTACK:
     PATCH /api/users/me
     {"name": "Alice", "bio": "hi", "role": "admin", "tenant_id": "OTHER"}
   The API doesn't reference `role` or `tenant_id` in its OWN handler
   code, but a generic `Object.assign(user, req.body)` -- style update
   helper (the exact shape of the historic Rails mass-assignment class of
   bug) writes BOTH fields to the record anyway. The account is now an
   admin in a DIFFERENT tenant's context.

   THIS IS NOT HYPOTHETICAL: in March 2012, a security researcher
   demonstrated the identical class of bug against GitHub's own Ruby on
   Rails codebase -- Rails' mass-assignment default at the time bound an
   ENTIRE incoming params hash to a model unless explicitly restricted,
   and the researcher used it to add his own SSH key to the `rails/rails`
   organisation itself, proving push access to the official repository.
   The fix that followed (`strong_parameters`, now Rails' default) is
   exactly the "reject unknown fields" rule above, built into the
   framework.

   FIX:
     - schema: `additionalProperties: false`, only `name` and `bio`
       listed -- the gateway/validation layer now REJECTS the payload
       above with a 400 before it reaches the update helper at all.
     - defence in depth: the update helper itself uses an explicit
       allowlist of bindable fields (a DTO, G1 Ch 45), not a generic
       merge -- so even a schema gap elsewhere doesn't reopen this path.
     - `role` and `tenant_id` are never client-settable fields on ANY
       endpoint; they're derived server-side from the authenticated
       principal (Part 5 Ch 24's token claims), never accepted as input.

Real-world scenario 2: feature composition creating an unintended payload

   Facebook disclosed in September 2018 that a chain of THREE separate,
   individually-reasonable features combined to expose access tokens for
   roughly 50 million accounts. In their own published account of the
   incident:
     1. The "View As" feature (letting a user preview their profile as
        seen by someone else) was supposed to be READ-ONLY.
     2. A video-uploader component, when rendered inside "View As" mode,
        incorrectly generated a fully-privileged access token FOR THE
        PROFILE BEING VIEWED AS, rather than a restricted, view-only
        context.
     3. A separate "Happy Birthday" post-composer bug caused that
        wrongly-scoped token to be exposed in the page's own payload,
        where an attacker automating requests against the "View As"
        flow could harvest it at scale.

   NONE of the three components was independently a classic injection
   or auth bug -- each was a case of a RESPONSE PAYLOAD carrying more
   than its calling context should ever have received (this chapter's
   API3:2023 "broken object property level authorization," Ch 40E). No
   single code review looking at any ONE of the three features in
   isolation would have caught it; the bug only existed in the
   COMPOSITION.

   LESSON FOR THIS CHAPTER: schema-based, POSITIVE validation of
   RESPONSE shape (not just request shape) per calling CONTEXT would
   have made this class of bug structurally harder -- if "View As" mode
   has its own strict response schema that simply has no FIELD capable
   of carrying a privileged token, a bug in an unrelated component
   can't smuggle one through it. This is why Ch 40A's schema discipline
   should be applied to what your API RETURNS, not only what it accepts.

Real-world scenario 3: payload shape enabling mass, automated scraping

   In January 2021, following the deplatforming of the social network
   Parler, security researchers and archivists were able to
   systematically download an estimated tens of terabytes of the
   platform's content -- including posts, videos, and their EMBEDDED
   METADATA (precise GPS coordinates in many cases) -- by walking
   SEQUENTIAL, PREDICTABLE numeric post IDs through Parler's own API and
   pulling the FULL response payload for each, including metadata fields
   that a normal web client would never display and that a properly
   scoped API response should never have included at all. Notably, even
   posts users had DELETED remained fetchable through the API for a
   period, because deletion had not actually removed the underlying
   payload the API continued to serve.

   TWO PAYLOAD-SECURITY LESSONS, DISTINCT FROM THE ACCESS-CONTROL
   LESSON (this is also a textbook API1/API9 case, Ch 40E):
     - the RESPONSE payload included far more than a client needed
       (precise geolocation metadata embedded in media) -- Ch 40A's
       "shape the response to exactly the fields the caller needs"
       principle, not just "does the caller have permission to see this
       object at all."
     - SEQUENTIAL, PREDICTABLE identifiers made systematic, automated
       enumeration of the ENTIRE payload space trivial -- opaque,
       random identifiers (UUIDv4, G1 Ch 45) don't fix a missing
       authorization check on their own, but they remove the "just
       count upward" enumeration path this incident relied on, and they
       combine with Ch 40B's rate limiting to make bulk harvesting
       materially harder rather than a simple incrementing loop.