react-doctor/supabase-client-owned-authz-field

When the client writes authorization columns (`ownerId`, `orgId`, `role`, `isAdmin`) to Supabase, an attacker can forge them and escalate their own access.

• Category: Security
• Severity: error
• Source: oxlint-plugin-react-doctor
• Framework: global
• Enabled when: client (browser-bundled) production source files; server dirs (api/backend/server/middleware/route/functions/lambdas/workers, *.server.*) skipped

Validation prompt

Use this to decide whether a fired diagnostic is real or a false positive.

Fires in client (browser) code only when BOTH signals are present: (a) a Supabase write — supabase…insert(/upsert(/update(, or .from(...) followed by insert/upsert/update( with an object/array-literal argument — that includes an authorization column (ownerId, creatorId, userId, orgId, tenantId, role, or isAdmin), and (b) a sensitive-field name (ownerId|creatorId|userId|uid|providerId|orgId|tenantId|teamId|workspaceId|role|roles|isAdmin|admin, with Id/ID variants) appearing in the file. The two-signal gate avoids flagging files that merely mention these names. FALSE POSITIVE: the written value comes from a trusted server context the client only echoes back (an authenticated session id, or a column an RLS with check policy independently re-verifies) rather than raw client input — confirm whether RLS actually constrains the column server-side.

Fix prompt

Use this once validation confirms the diagnostic is real.

Stop sending owner, org, tenant, or role columns from the client; let the database set them. Default user_id to auth.uid(), derive org and role from server-owned membership rows, and enforce it with an RLS with check policy so a forged ownerId or role in the payload is rejected. Move any genuinely privileged write behind a server route or a security definer Postgres function that validates the actor.