Mass assignment vulnerabilities
Mass assignment happens when a framework binds untrusted request fields directly to internal objects that contain sensitive properties.
What it means
Mass assignment happens when a framework binds untrusted request fields directly to internal objects that contain sensitive properties. Attackers may supply fields the interface never displayed. Authorization-sensitive state should be controlled by trusted logic rather than by unrestricted object binding.
A practical example
A profile update accepts a nickname and biography. If the same model also contains an administrator flag, blindly copying the request into it could change privileges. A dedicated request model exposes only the approved profile fields.
What to check
Allowlist writable fields for each operation. Separate transport objects from persistence models and test unexpected nested properties, privilege flags, ownership fields, and fields normally controlled by workflow state.
A common pitfall
Hiding a field in the user interface does not stop a caller from sending it. Parameter binding is a convenience feature, not an authorization decision.
Think it through
Should a profile update trust a role field because it matches the database schema?
Answer: No. The endpoint must accept only fields that this operation and caller are allowed to change.
Public fields and internal fields are different contracts
A fictional membership service stores display name, email, role, and account status in one model. Its profile-update endpoint should let a member change only selected fields. Binding the incoming request directly to the entire persistence model can accidentally expose role or status changes even when those controls are absent from the user interface.
The safer boundary is an explicit update contract. Create a request model containing only the fields this operation permits, validate those fields, and apply them deliberately. Separate contracts may be appropriate for self-service updates and administrative changes. An administrator's broader operation still needs its own authorization rather than inheriting trust from the model binder.
Nested structures and future schema changes deserve attention. A new internal property added to a database model should not silently become writable through every endpoint using that model. Explicit request objects help prevent this coupling. Review serializer and framework defaults to understand how unknown properties and nested objects are handled.
Inspect a profile-change request
For a local exercise, list the fields a member may change and those maintained only by the server. Prepare a normal display-name update and an extra unsupported property using dummy accounts. State whether the endpoint rejects the request or ignores the property, and verify that internal state remains unchanged.
The same distinction applies to response exposure: an internal model may contain fields that should never be serialized to a client. Review inbound assignment and outbound serialization independently. A useful regression case protects the public contract when the internal schema grows, preserving normal profile editing while ensuring that new privileged properties do not become user-controlled by accident.
Related concepts
References & further reading
Original explanations, with primary references for deeper study.
OWASP: Mass Assignment