Mass Assignment

What Is Mass Assignment?

Mass assignment (OWASP API6:2019), also called auto-binding or over-posting, happens when an API takes a client's request body and binds every field it contains onto an internal object, with no list of which fields a client is actually allowed to set. The classic shape: a create or update endpoint copies the whole payload onto a model, so a client can set fields the form never exposes, an admin flag, a verified status, a balance, a role, simply by adding them to the request. It is distinct from broken object level authorization, where the caller reaches an object that is not theirs, and from a token-forging privilege escalation, where the caller tampers with their own credential; here the token is honest and the object is correctly the caller's own, and the missing control is which fields of that object the caller may write. This exercise puts you on both sides. As Bob, a genuine member of Perklane's retail rewards app, you read your own profile and see the editable fields sitting in the same record as your points balance and tier, then send a normal profile update and, on the next call, add the balance and tier fields to the same body, and the server writes them, giving your own account half a million redeemable points from two extra JSON keys. As Alice, the backend engineer who owns the member-account API, you open the update handler on the receiving end of a finance alert, see that it binds the whole request body onto the member record, and ship the fix: read only the fields a profile edit is meant to change from the request and apply just those, so any other key is never referenced and cannot reach the record. The exercise closes with quiz questions on why an ownership check or a role guard cannot fix a field-level binding gap, why an allow-list beats a block-list, why the patched endpoint returns 200 while silently dropping the privileged fields, and how mass assignment differs from BOLA.

What You'll Learn in Mass Assignment

• Recognize mass assignment: an API binds every field in a client's request body onto a stored object, so a client can set fields it should never control by adding them to the request
• Distinguish it from broken object level authorization (reaching an object that is not yours) and token-forging privilege escalation (tampering with your own credential); here the token is honest and the object is correctly the caller's own, and the missing control is field-level
• See how a legitimate self-service edit becomes fraud when the handler writes client-supplied fields that only an internal process should set, such as a points balance or account tier
• Apply the fix: replace a blind bind of the whole body with an explicit allow-list of the fields an operation may write, and ignore every other key
• Understand why an allow-list beats a block-list, why the patched endpoint succeeds with 200 while dropping non-writable fields, and audit every create and update handler for the same blind bind

Mass Assignment — Training Steps

1. An ordinary member

   Perklane is a retail rewards app: members earn points on purchases and redeem them for gift cards in the app. Bob signed up as a normal member, with a throwaway identity, to see how far an ordinary account can push. His account is nothing special: a plain member seat with a token that reads and edits his own profile. He opens the developer console to see what the account API gives him.

2. One object, two kinds of field

   Bob's profile card shows the fields the app lets him edit, and next to them the values the app keeps about him. The API reference shows how the app reads and saves that profile.

3. Read his own profile

   First Bob calls the endpoint the way it is meant to be used: he asks the API for his own profile, carrying his own member token in an Authorization header, exactly as the app does.

4. His profile, every field

   The server returns exactly what it should: Bob's own profile, because he asked for his own record with his own token. Nothing is wrong here. But the shape of the record is worth a close look.

5. Make a normal edit

   Bob uses the feature as intended first: a plain profile edit. He switches the request to the save method and sends a new display name and avatar, the two fields the profile form actually offers.

6. The edit takes

   The save worked. The display name and avatar changed, and everything else stayed put.

7. See the edit on his profile

   Before pushing further, Bob does what any member would after saving: he reloads his account page. Whatever the save wrote to his record is what the page reads back.

8. Add the fields the form never shows

   Same request, same token, same endpoint. Bob keeps his display name and avatar in the body and adds two more keys, the exact field names the read call handed him: the points balance and the tier. If the save merges whatever it receives, it will write these too.

9. The balance he never earned

   It took all of it. Bob's own profile now says he has half a million points and a platinum tier, set by nothing more than two extra keys in a profile edit.

10. See it on his profile

    The API returned 200, but Bob wants to see it the way any member would. He reloads his own account console: whatever the save wrote to his record is what the page will read back.