Mass Assignment.

Mass assignment occurs when frameworks (Rails, Spring, ASP.NET, NestJS, Django) automatically map incoming JSON or form fields onto model attributes without an explicit allow-list. An attacker adds extra properties — isAdmin, role, balance, tenantId — that the server then persists. The flaw is hard to spot in review because the binding is implicit: a single update_attributes(params) or model-binder call hides the fact that every attribute is writable. It is catalogued as CWE-915 and appears in the OWASP API Security Top 10 (2019 A6, merged into API3 "Broken Object Property Level Authorization" in 2023).

The canonical incident is Egor Homakov's March 2012 GitHub hack: because the SSH-key form bound public_key[user_id] without a whitelist, he added a crafted field, attached his key to the Rails organisation account and pushed a commit to rails/rails. GitHub patched within hours, and the episode drove Rails to make attr_accessible whitelisting — later strong_parameters — the default.

Mitigations include explicit DTOs or input schemas, strict allow-lists of bindable fields, separating internal-only attributes from user-bindable models, and negative tests that submit unexpected JSON keys.

flowchart TD
  A["Client POSTs JSON<br/>{name, isAdmin:true}"] --> B[Framework auto-binder]
  B --> C{Explicit allow-list<br/>of fields?}
  C -->|No — mass assignment| D[All keys written to model]
  D --> E[(isAdmin=true<br/>persisted to DB)]
  C -->|Yes — DTO / strong params| F[Only permitted fields bound]
  F --> G[(Privileged fields ignored)]