This one has a slightly awkward technical name, mass assignment, or sometimes over-posting, and a much simpler plain-English version: a form only shows you a few fields, but the code behind it saves whatever fields it's handed, whether or not the form intended to offer them.
How this actually happens
A common, convenient pattern in fast-built apps is to take the entire incoming request and save it directly to a database record in one step, rather than explicitly picking out only the specific fields the form was meant to collect. This is faster to write and works perfectly for the visible form, since the form only ever sends the fields it displays. The problem is that the visible form isn't the only way to send a request. Anyone can open their browser's dev tools, or use a basic request tool, and send the exact same request with extra fields added, fields the form never showed but the underlying database record happens to have, like a role, a permission level, or an account status.
A concrete, hypothetical walkthrough
Picture a signup form asking for a name and an email. Behind the scenes, the user record it creates also has an isAdmin field, defaulting to false, used elsewhere in the app to decide who gets elevated access. If the signup endpoint takes the entire submitted request and saves it directly, someone can submit the normal name and email fields, plus an extra isAdmin field set to true, tacked onto the same request outside the form's own interface. If nothing on the server explicitly ignores that extra field, the new account gets created with admin access, granted by the visitor, not by anyone who was supposed to grant it.
Why this is easy to miss
The form itself never shows an option to set admin status, so testing the form normally never reveals the gap. The bug isn't in what the form displays. It's in what the endpoint underneath accepts from a request that didn't come through the form's interface at all.
How to actually check for this
- Look at any endpoint that creates or updates a record directly from submitted data, and check whether it explicitly lists which fields are allowed, or whether it just saves everything it receives.
- Using dev tools or a request tool, try submitting a normal form's request with an extra field added, something that maps to a sensitive column in your database, a role, a permission flag, a status.
- If that extra field actually changes something in the resulting record, the endpoint needs an explicit allow-list of fields, rather than accepting the whole request as-is.
The fix
Explicitly define which fields an endpoint is allowed to accept and save, and ignore everything else in the request, rather than saving the entire submitted object directly. Most frameworks have a standard, well-documented pattern for exactly this. It's a small, mechanical change once you know to look for it, and it closes off an entire category of "the form didn't offer this, but the request accepted it anyway" bugs at once.