Mass assignment: users can set fields like role or is_admin

Steps

1. Find every create and update route, server action or edge function, and look for code that spreads or passes the entire request body into an ORM or database call.
2. On your own app, send an update request with an extra field (for example "role":"admin" or "plan":"pro") and check whether it was saved.
3. Replace whole-body binding with an explicit allow-list of the fields the caller may edit, or a dedicated input schema (zod, a DTO) that strips everything else.
4. Keep sensitive columns (role, plan, credits, owner or tenant IDs, verified flags) server-controlled only. Set them from the authenticated session or a trusted backend job, never from client input.
5. In Supabase or Postgres, back this up with RLS policies and column privileges so a client key can't update protected columns even if app code slips.
6. Apply the same rule to responses: return only the fields the client needs, not the whole row.

Why it matters

OWASP's Mass Assignment Cheat Sheet explains that frameworks which auto-bind request parameters into objects let attackers create or overwrite fields the developer never intended, and recommends dedicated input objects and explicit allow-lists rather than relying on a block-list. OWASP's API Security Top 10 (2023) folds mass assignment into API3: Broken Object Property Level Authorization.

Sources

OWASP Mass Assignment Cheat Sheet — https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html

OWASP API Security Top 10 2023, API3: Broken Object Property Level Authorization — https://owasp.org/API-Security/editions/2023/en/0xa3-broken-object-property-level-authorization/

Related patterns

• RLS or auth present, but no ownership check (IDOR)
• API routes with no auth check
• Row Level Security disabled on Supabase tables