Offensive security assessments
Mass Assignment (API3:2023)
Mass Assignment happens when an API binds client-supplied JSON directly to an internal object or database model. If the binding is not filtered by an allowlist, an attacker can set fields they were never meant to control, such as role, isAdmin, verified, balance, accountid, or p…
Why it matters
OWASP API3:2023
A single unfiltered JSON field can escalate a standard user to admin or alter financial balances. These bugs are common in rapid API development where frameworks auto-bind request bodies to database models.
How we test it
Our operators follow a structured checklist for this topic, adapted to your API surface and authentication model.
Testing approach
- Capture baseline GET responses and replay write requests with every returned field.
- Add guessed privileged keys: role, isAdmin, verified, balance, accountId, price.
- Test nested objects and arrays on PATCH/POST/PUT endpoints.
- Combine with IDOR: attempt to write privileged fields on another user's object.
What we look for
- Registration and profile endpoints accepting server-controlled fields.
- Frameworks auto-binding without DTO allowlists (Rails, Spring, Django, Laravel, NestJS).
- Responses exposing more fields than the UI form, hinting at bindable properties.
How to fix it
Remediation guidance
- Bind to explicit allowlists; never map request JSON directly to persistence models.
- Separate request and response schemas; mark sensitive properties read-only server-side.
- Validate object-property-level authorization for each writable field.
Related topics
| Topic | Summary |
|---|---|
| GraphQL | The Schema defines the capabilities of the API and represents the contract between the client and the server. It defines the types available in the API and how they can be queried and mutated. |
| Rest API | We validate this area during scoped assessments, documenting impact and remediation guidance. |