Mass Assignment occurs when untrusted input is automatically bound or deserialised into program objects without properly restricting which fields can be set. An adversary can exploit this by supplying unexpected parameters to modify sensitive fields (e.g., `isAdmin`, `role`, `balance`) or manipulate database records directly. Many language frameworks provide permissive default behaviour where all object properties are writable unless explicitly protected.
Remediation
Never expose domain models directly to external endpoints.
Use dedicated Data Transfer Objects (DTOs) or whitelists to explicitly define which fields can be updated.
Mark sensitive properties (e.g., user roles, permissions, account balances) as immutable or read-only in your domain models.
Use framework-specific security features such as parameter whitelisting (`strong_parameters` in Rails, `BindNever` in .NET) to prevent unintended binding.
Perform strict input validation on all incoming fields to prevent injection of unexpected attributes.
Metadata
Severity: high
Slug: mass-assignment
CWEs
915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
639: Authorization Bypass Through User-Controlled Key
285: Improper Authorization
471: Modification of Assumed-Immutable Data (MAID)
OWASP
A08:2021: Software and Data Integrity Failures
A01:2021: Broken Access Control
Available Labs
Select a language to explore available labs for this vulnerability.
Want to skill-up in secure coding and AppSec?
Try SecDim Wargames to learn how to find, hack
and fix security vulnerabilities inspired by real-world incidents.
Join our secure coding and AppSec community.
A discussion board to share and
discuss all aspects of secure
programming, AppSec, DevSecOps,
fuzzing, cloudsec, AIsec
code review, and more.
