api-mass-assignmentlisted

# Mass assignment (BOPLA) ## When it applies An endpoint deserializes client JSON straight into a data object without an allowlist of writable fields. You add sensitive properties the developer never meant to be client-writable. ## Why it works Frameworks that auto-bind request bodies to models will set *any* matching attribute unless explicitly restricted. If `role`, `isAdmin`, `account_balance`, `email_verified`, or `user_id` are bindable, you set them by just including them in the body. ## Method 1. **Learn the object shape**: read a GET response for the object — every returned field is a candidate writable property. Also mine JS, mobile apps, and API docs for hidden fields. 2. **Inject sensitive fields** into create/update requests: `{"username":"x","password":"y","role":"admin"}` or `"isAdmin":true`, `"verified":true`, `"balance":999999`, `"user_id":<victim>`. 3. **Guess conventions** when fields aren't leaked: `is_admin`, `admin`, `roleId`, `groups`, `permissions`, `account_type`, `tenant_id` — try nested objects too (`{"role":{"id":1}}`). 4. **Chain**: set `user_id`/`owner_id` to a victim to combine with IDOR, or flip `verified` to skip email/2FA gates. ## Gotchas - Extra fields silently ignored ≠ safe — confirm by reading the object back for your change. - Some frameworks need the exact case/nesting; mirror the GET response structure. - The writable field may only take effect on a specific endpoint/verb (create vs update). ## Verify success A privi