Home / patterns

RLS or auth present, but no ownership check (IDOR)

Quick answer: Row Level Security or login may be on, yet policies and API routes never confirm the signed-in user owns the row — so changing an id can leak another user's data.

Last updated October 15, 2026

Steps

  1. Create two test accounts (User A and User B) in your own app.
  2. As User A, note a record id that belongs only to you (an order, note or profile row).
  3. Sign in as User B and request User A's id through your API or client (for example GET /api/.../{id}).
  4. If User B can read or change User A's data, ownership is missing — fix RLS policies and server routes so every query filters on auth.uid() (or your user id) matching the row owner.
  5. Retest with both users after the fix.

Why it matters

Supabase documents that the publishable (anon) key is safe in the browser only when RLS policies correctly restrict rows: https://supabase.com/docs/guides/database/secure-data and https://supabase.com/docs/guides/database/postgres/row-level-security

Launch checklists for vibe-coded apps call out ownership checks on API routes alongside RLS: https://rivetzco.com/checklist

Self-check your own app only. Never probe apps you don't own.

Related patterns

  • Row Level Security disabled on Supabase tables
  • API routes with no auth check

Want an expert to check your app?

VibeRescue checks are coming soon. Join the waitlist, or ask StorenTech AI to fix it for you.

Join the waitlist

Vibe Security Weekly

One email a week with new failure patterns and how to fix them.

Free. Unsubscribe anytime. We'll never sell your email.