API Security and Mass Assignment

This Vulnerability Explain post covers API Security with a focus on Mass Assignment. As apps shifted to API-first designs, a class of bugs followed – especially the automatic binding of request data to internal objects. Let’s look at mass assignment and the broader API risks around it.

What is API Security?

Mass Assignment happens when a framework automatically binds client-supplied request fields to object properties or database columns, and the application does not restrict which fields are allowed. The attacker adds fields they were never meant to set.

Imagine a profile update endpoint that accepts a JSON body and maps it straight onto the user model. The form only shows name and email, but the user object also has an isAdmin field. By adding “isAdmin”: true to the request, the attacker escalates to admin because the binding blindly accepted it.

How does API Security work?

Mass assignment and related API flaws unfold like this:

• Automatic Binding
  • The framework maps all incoming fields onto the model without an allowlist.
• Hidden Sensitive Properties
  • The model contains sensitive fields (role, isAdmin, balance, verified) not shown in the UI.
• Extra Fields Injected
  • The attacker adds those properties to the request body.
• Properties Overwritten
  • The binding sets the sensitive fields from attacker input.
• Privilege or Data Abuse
  • The attacker escalates privileges, alters balances, or bypasses verification.

Mass assignment is the API trusting the shape of the request to match intent. Define exactly which fields a client may set, and the trust is no longer misplaced.

How mass assignment works: extra request fields are bound to internal object properties.

Tools and Techniques for API Security Testing

Testing involves adding unexpected fields and probing object-level authorization across the API.

Manual Testing Methodologies

• Field Injection – Add properties like role, isAdmin, or id to request bodies and check whether they take effect.
• Schema Discovery – Use API responses and docs to learn the full object model, then target hidden fields.
• Object-Level Auth Testing – Combine with IDOR checks to access other users’ objects.
• Method and Version Probing – Test older API versions and alternate methods that may lack protections.

Automated Scanning Tools

• Astra – Automated REST API security testing.
• Kiterunner – Discovers API endpoints and routes.
• Burp Suite Scanner – Helps test API parameters and authorization.
• Nuclei – Templates for common API misconfigurations.

API Security Protection Mechanisms

Best Practices for Secure Coding

• Use Field Allowlists
  • Description: Bind only an explicit set of permitted fields from the request.
  • Benefits: Extra fields are ignored, killing mass assignment.
  • Implementation Tip: Use Data Transfer Objects (DTOs) or strong parameter filtering.
• Separate Input and Persistence Models
  • Description: Do not bind request bodies directly onto database entities.
  • Benefits: Sensitive properties are never reachable from input.
  • Implementation Tip: Map validated DTO fields to the entity manually.
• Enforce Object-Level Authorization
  • Description: Check the user may modify the target object and its sensitive fields.
  • Benefits: Combines with allowlists to stop escalation.
  • Implementation Tip: Re-verify role-changing fields with a dedicated, privileged flow.

Best Practices for Organizations

• API Governance
  • Define and document API schemas and required authorization.
  • Review new endpoints against an API security standard.
• Follow OWASP API Top 10
  • Address broken object-level and property-level authorization.
  • Adopt consistent input validation.
• Testing
  • Add mass assignment and IDOR tests to CI.
  • Pentest APIs separately from the UI.

Top API Security payloads used by Security Researchers

As a security researcher, knowing the most common payloads helps you detect and prevent these attacks. Use this knowledge ethically and only on systems you are authorized to test. Some sample payloads are shown below.

// Mass assignment privilege escalation
PATCH /api/users/me
{ "name": "Alice", "email": "a@x.com", "isAdmin": true }

// Setting an internal balance field
POST /api/wallet
{ "currency": "USD", "balance": 1000000 }

// Overwriting ownership
PUT /api/orders/55
{ "status": "paid", "userId": 1 }

// Self-verifying via hidden field
PATCH /api/account
{ "emailVerified": true }

Real-World Example: isAdmin Through Profile Update

A mobile app’s profile update API bound the entire JSON request body straight onto the User database model using the framework’s default behavior.

A tester added “isAdmin”: true to the otherwise normal profile update request. The framework dutifully set the field, and the account became an administrator – a full privilege escalation from a routine settings change.

The fix introduced a DTO that accepted only name and email and mapped them explicitly to the model. Mass assignment is the API equivalent of leaving every door unlocked – define exactly which fields a client may set and lock the rest.

Vulnerable and secure code of API Security

The following example shows the contrast between vulnerable and secure code for API Security. It helps you see how the flaw creeps into real code and the changes that shut it down.

🥺 Vulnerable Code:

// Vulnerable: whole request body bound onto the user model
app.patch("/api/users/me", async (req, res) => {
  const user = await User.findById(req.user.id);
  // Any field in the body is applied - including isAdmin
  Object.assign(user, req.body);
  await user.save();
  res.json(user);
});

• Object.assign copies every field from the request, including hidden ones.
• Adding isAdmin: true to the body escalates the account to admin.

😎 Secure Code:

// Secure: explicit allowlist of updatable fields
app.patch("/api/users/me", async (req, res) => {
  const user = await User.findById(req.user.id);
  const allowed = ["name", "email"];          // nothing else can be set
  for (const key of allowed) {
    if (key in req.body) user[key] = req.body[key];
  }
  await user.save();
  res.json({ name: user.name, email: user.email });
});

• Only name and email are ever copied from the request.
• Sensitive fields like isAdmin can never be set through this endpoint.

Conclusion

API Security and Mass Assignment come down to never trusting the shape of a request to match its intent. Bind only an explicit allowlist of fields, keep input models separate from database entities, enforce object-level and property-level authorization, and follow the OWASP API Top 10. Decide exactly what a client may set, and attackers lose the extra fields they rely on.