AI-Generated Mass Assignment Review Rules

Purpose

Use these rules when an AI coding assistant writes or edits code that binds request data onto a model, entity, or ORM object. The goal is to stop a generated create/update endpoint from letting a client set fields it was never meant to control — an admin flag, an ownership reference, a price — just by adding an extra request parameter, because the binding code accepted the whole request body by default.

This is a review policy, not a mass-assignment tutorial. It tells reviewers what must be true about a generated change's request-to-model binding before the change is safe to merge.

Review Inputs

Collect enough context to know what gets bound and what's sensitive on it.

• Every place the change binds request data (JSON body, form fields, query parameters) onto a model, entity, or ORM object, whether through framework autobinding or hand-written field-copying code.
• Which fields on the target model/entity are sensitive: privilege/role flags, ownership or user-ID references, financial fields, verification or approval status, anything that should only ever be set by trusted server-side logic.
• Whether the framework in use autobinds by default (Spring MVC, ASP.NET MVC, Rails, many ORMs) and what its allowlist/block-list mechanism is.
• Whether create and update paths for the same model use the same binding code or different, independently-reviewed paths.

Binding Rules

• Require an explicit allowlist of bindable fields per endpoint — never accept "whatever fields the request includes" onto a full model object.
• Flag any sensitive field (privilege/role, ownership, financial, status) that's reachable through a binding path without an explicit allowlist or block-list excluding it.
• Prefer a dedicated DTO / input schema per endpoint over binding directly to the persistence model: a field the DTO doesn't declare can't be mass-assigned even if present in the request.
• Do not assume a framework's default autobinding is safe; confirm its specific allowlist/block-list mechanism (Spring's @InitBinder setAllowedFields/setDisallowedFields, Rails strong parameters, a Mongoose schema pick/omit list, a serializer/DTO elsewhere) is actually configured for every bindable model in the diff.
• Give update endpoints the same scrutiny as create endpoints — rebinding a full request body onto an already-loaded entity on update can overwrite fields the create path's DTO protected.

Exploitability Rules

• Treat a sensitive field as exploitable mass-assignment risk when: an attacker can guess or discover the field name (from public source, docs, or a client bundle), and the binding path has no allowlist/block-list excluding it — both conditions are commonly true for AI-generated code that mirrors the model's real field names in API docs or client code.
• Remember this vulnerability goes by different names per stack — mass assignment (Rails, Node), autobinding (Spring MVC, ASP.NET MVC), object injection (PHP) — review binding code in every language present in the diff, not just the one the reviewer is most familiar with.
• Confirm the fix uses an allowlist (only named safe fields bindable) rather than a block-list alone where practical — a block-list must be kept in sync with every new sensitive field added later, while an allowlist fails closed by default.

Merge Blockers

Block merge when any of these is true.

• A create or update endpoint binds request data onto a model/entity with no allowlist, block-list, or DTO restricting which fields can be set.
• A sensitive field (privilege/role, ownership, financial, verification status) is reachable through a binding path with no explicit protection.
• An update endpoint uses different, less-restrictive binding than the create endpoint for the same model.
• A framework's autobinding is relied on with its default configuration, with no allowlist/block-list mechanism actually applied.

Review Checklist

• {"task": "Binding paths identified", "description": "Every request-to-model binding path in the change is identified, including framework autobinding"}
• {"task": "Allowlist or DTO present", "description": "Each binding path restricts to an explicit allowlist of fields or uses a DTO that excludes sensitive ones"}
• {"task": "Sensitive fields protected", "description": "Privilege/role, ownership, financial, and status fields are not reachable through any unprotected binding path"}
• {"task": "Create and update both covered", "description": "Update endpoints get the same binding scrutiny as create endpoints for the same model"}
• {"task": "Framework default not assumed safe", "description": "The framework's specific allowlist/block-list mechanism is confirmed configured, not just assumed"}

AI Review Rules

AI assistants can write and review request-binding code, but they should show their evidence.

• Ask the assistant to list every request-to-model binding path in the change, including any framework autobinding it relies on implicitly.
• Require the assistant to state, for each bindable model, which fields are sensitive and how the binding path excludes them.
• Have the assistant confirm update endpoints don't silently gain broader binding than their corresponding create endpoint.
• Do not let the assistant claim a binding path is safe because the happy- path test only sent the intended fields.
• Re-run review after any change to a model's fields, a binding configuration, or a shared DTO/serializer.

Troubleshooting

• A legitimate admin-only field needs to be settable by some requests: give the admin-facing endpoint its own DTO/allowlist that includes it, separate from the general user-facing endpoint's DTO.
• Switching to a DTO breaks a field the client actually needs to set: add that specific field to the DTO deliberately, rather than reverting to full-model binding.
• Tests only cover intended fields: add a test that includes an extra, unintended field (e.g. a role/admin flag) in the request and asserts it was not applied to the resulting object.
• An update endpoint needs different bindable fields than create: give it its own explicit allowlist/DTO rather than reusing the create path's binding code unchanged.

Duplicate And History Check

Before adding a new binding path, confirm the codebase does not already have a shared DTO, serializer, or allowlist configuration for this model. A generated change that binds directly to the model next to an existing protected DTO for the same entity should be treated as suspicious — check whether the existing mechanism was simply not reused before introducing a second, unprotected binding path.

Reference

Sources

• OWASP Mass Assignment Cheat Sheet
• CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes
• OWASP API Security Top 10 2023 — API3: Broken Object Property Level Authorization
• GitHub Blog: Public Key Security Vulnerability and Mitigation (2012 mass assignment incident)

• Source repositorygithub.com 2026-07-16T13:01:56+00:00
• Documentationcheatsheetseries.owasp.org
• Submitted by lourincedaging0-commits2026-07-15