mass-assignment

name	mass-assignment
description	Detects ORM create/update calls that spread request bodies without an explicit field allowlist. Use when writing code that creates or updates database records from request body, form data, or JSON input. Also invoke when spreading, merging, or destructuring request payloads directly into ORM model create/update calls without an explicit field allowlist.

Mass Assignment Check (API3:2023)

What this checks

Protects against mass assignment (also called auto-binding or object injection) where an attacker adds unexpected fields like role=admin or is_verified=true to a request body and the ORM blindly persists them. Exploitation leads to privilege escalation, account takeover, and data corruption.

Vulnerable patterns

• ORM create or update call that spreads, merges, or destructures the raw request body, deserialized payload, or query parameters into the model
• DTO-to-entity copy utility invoked with no field allowlist or exclude list, copying every matching field
• Decoded payload bound directly into a database struct or record that includes privileged columns
• Endpoint that lets the caller set fields like role, permissions, admin flags, verification status, balance, or tenant id from the payload

Fix immediately

Flag the vulnerable pattern and explain the risk. Then suggest a fix that establishes these properties:

1. No ORM create/update call receives the raw request body. Requests land in a dedicated input type (DTO, validated schema, typed struct, sealed class) that contains only the fields external callers may set. Fields the input type does not mention are silently dropped by the deserializer.
2. Privileged fields are set server-side, never from input. Roles, permissions, admin flags, verification status, balances, owner ids, and tenant ids come from the authenticated session or database defaults — never from the payload, even after "validation".
3. DTO-to-entity copy utilities copy only named fields or explicitly exclude protected ones. A blanket field-by-field copy with no ignore list is the exact bug — the safe form names the fields.
4. The allowlist lives next to the type, not scattered at call sites. A filter set repeated at every endpoint is brittle; the typed input pattern makes omission a compile-time (or deserialization-time) guarantee.

Translate these principles to the ORM, validation library, and deserializer of the audited file's language. Use the framework's documented allowlist or typed-input mechanism — do not hand-roll field filtering at the call site.

Verification

Confirm the following properties hold (language-agnostic):

• No ORM create/update call receives the raw request body, deserialized payload, or spread/merged object without an explicit field allowlist or a dedicated input type that excludes sensitive columns
• Privileged fields (role, permissions, is_admin, is_verified, balance, owner_id) are never settable from external input — they are set server-side or omitted from the input type
• If a DTO-to-entity copy utility is used, it either copies only named fields or explicitly excludes protected fields

References

• CWE-915 (Improperly Controlled Modification of Dynamically-Determined Object Attributes)
• OWASP API3:2023 Broken Object Property Level Authorization