Mass Assignment

What Is Mass Assignment?

An API copies every field in a request body onto an internal object, with no list of which fields a client may set. The token is honest and the record is the caller's own. What is missing is a field-level control. You'll send a normal profile update, then the same update with two extra JSON keys, and the server writes both. The fix reads only the fields a profile edit is meant to change. An ownership check or a role guard cannot close a field-level gap.

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.