Mass assignment testing
Mass assignment (property-level authorization failure) is when an API takes the fields in a request and binds them straight onto your data model — so a user can set fields they were never meant to, like role=admin, is_verified=true or balance. Sintropyc tests every write endpoint for extra-field injection and proves each one that sticks.
How mass assignment happens
It's a convenience that turns into a vulnerability. A framework binds the whole request body to an object (User(**request.json), update(req.body)), and any field the client sends — not just the ones the form shows — gets written. The UI never exposes role; the API accepts it anyway.
Fields attackers try to set
- Privilege —
role,is_admin,permissions,plan - Trust flags —
is_verified,email_verified,approved - Ownership —
user_id,org_id,owner— reassigning a record to yourself or another tenant - Money and limits —
balance,credits,price,discount - Internal state —
status,created_at, hidden workflow fields
How Sintropyc tests it
Sintropyc is an autonomous AI penetration testing agent. It signs in as real users across different roles, drives your product the way a customer would, and proves every finding with a working exploit — never a scanner guess. Each finding is checked by a human before it reaches you, comes with the exact fix, and is attacked again after you ship it to confirm it held.
For mass assignment, Sintropyc reads each write endpoint's real model (from responses, schema or observed traffic), injects sensitive extra fields into create and update requests, and checks whether they were actually saved and honored. A finding is reported only when an injected field takes effect — proven with the request and the resulting privilege or state change.
Property-level authorization sits alongside object-level (BOLA) and function-level failures as a top API risk — and it's invisible until someone sends the extra field.
What you get
- Every create / update endpoint tested for extra-field injection
- Proven writes to privilege, ownership and money fields
- The fix (explicit allow-lists / DTOs; never bind the raw body) per finding
- A retest after you ship it
Common questions
Isn't this just an input-validation bug?
It's an authorization bug: the field is valid, but the user isn't allowed to set it. That's why it needs testing as different users, not just schema validation.
Do you test GraphQL mutations too?
Yes. Over-permissive mutation inputs are a common mass-assignment vector, and they're covered alongside REST.
How is it related to BOLA?
Both are API authorization failures: BOLA is object-level (reaching another's record), mass assignment is property-level (setting fields you shouldn't). API authorization testing covers both together.