Mass Assignment Vulnerabilities: When Extra Fields Become Admin Access

Mass assignment happens when an application takes a request body and copies it directly onto a database model. If the model has fields users should not control, an attacker simply adds them to the request.

A simple example

A profile update endpoint:

app.patch("/api/me", auth, async (req, res) => {
  const user = await db.user.update({ where: { id: req.user.id }, data: req.body });
  res.json(user);
});

The frontend sends {"name": "Ana"}. An attacker sends:

{ "name": "Ana", "role": "admin", "emailVerified": true, "orgId": "victim-org" }

If the model has those fields, the attacker just became an admin, verified an unowned email and moved into another organisation.

Fields attackers look for

• role, isAdmin, permissions, scopes
• emailVerified, status, approved
• orgId, tenantId, ownerId, userId
• price, discount, credits, balance, plan
• createdAt, id, internal flags

Attackers find candidate field names in API responses, frontend code, documentation, error messages and GraphQL schemas.

Why it happens

Frameworks make it convenient to bind request data to models. ORMs accept objects. AI code assistants often generate data: req.body because it is the shortest working code. It works perfectly in normal use, so nobody notices.

How to prevent mass assignment

1. Allowlist writable fields explicitly.

const { name, avatarUrl } = req.body;
await db.user.update({ where: { id: req.user.id }, data: { name, avatarUrl } });

2. Validate with a strict schema that rejects unknown fields.

const UpdateMe = z.object({ name: z.string().max(100), avatarUrl: z.string().url().optional() }).strict();
const data = UpdateMe.parse(req.body);

3. Use separate input types or DTOs for each operation, rather than reusing the database model.

4. Use framework protections, such as strong parameters in Rails, or explicit field binding in other frameworks.

5. Set sensitive fields server-side only, for example orgId from the session, never from the body.

Related: excessive data exposure

The read-side twin of mass assignment is returning whole models in responses, exposing internal fields. Together, the OWASP API Security Top 10 groups them as Broken Object Property Level Authorization (BOPLA). Serialise responses through explicit output schemas.

Testing for mass assignment

Testing adds plausible privileged fields to create and update requests, then checks whether they took effect. SecurityInfinity agents infer field names from responses and schemas and test them across endpoints, reporting only confirmed changes. Start free.

Frequently asked questions

Is mass assignment the same as parameter tampering?

It is a specific form. Parameter tampering changes existing parameters; mass assignment adds parameters the server did not expect but accepts.

Does TypeScript prevent mass assignment?

No. Types do not exist at runtime, so extra fields in JSON still arrive unless you validate with a runtime schema.

How severe is it?

It can be critical when it allows privilege escalation or cross-tenant access, and low when only harmless fields are writable.