Glossary
What Is Mass Assignment?
Mass Assignment is a vulnerability where an application binds user-controlled input to a domain model without filtering which fields can be set. The classic exploit: send a JSON body with an unexpected field ("isAdmin": true) on a PATCH request, and the field is written to the database because the framework spreads the input onto the model. CWE-915 is the canonical identifier; OWASP API Security Top-10 lists it as API6:2023.
Why mass assignment is common
Modern frameworks make object binding easy: Spring's @ModelAttribute, Django REST framework's ModelSerializer, Rails' params.permit(...), .NET's model binding. The default is "bind everything that fits." Developers explicitly filter on the create flow (registering a user shouldn't let them set role) but forget the update flow — or the second update flow they added six months later. The vulnerability ships when the binding flow runs over a model with privileged fields (isAdmin, tenantId, role, balance, verifiedAt) without an allowlist.
How SQUR detects mass assignment
The exploitation planner identifies endpoints accepting structured input (JSON, form-encoded) and mapping to update/create operations. The validator constructs payloads with privileged-field guesses (isAdmin, role, tenant_id, is_verified, balance, permissions) and re-reads the resource to confirm the field changed. If the validator can promote a non-admin user to admin via PATCH, the finding is confirmed with the before/after state captured.
Remediation pattern
Use explicit field allowlists on every binding: Rails params.require(:user).permit(:name, :email), Django REST fields = ('name', 'email'), Spring binding result with @JsonProperty allowlists. Apply field-level authorization: even if a user can set their own email, they cannot set another user's. Audit: search the codebase for binding patterns and assert each one has a field allowlist.
Frequently asked questions
Why is this in our pentests so often?
Frameworks make the safe path opt-in, not default. The bug appears when a team copies the create flow into update, copies the update flow into bulk-update, and adds privileged fields later. SQUR's recent assessments find mass-assignment exploits in roughly 1 in 5 B2B SaaS APIs.
Is mass assignment the same as BOLA?
BOLA is missing ownership check across resources. Mass assignment is missing field-level allowlist within one resource. They're both authorization bugs but different layers — BOLA is "can user A reach user B's resource?"; mass assignment is "can user A change a field they shouldn't be able to?". Often co-occur.