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
- Create two test accounts (User A and User B) in your own app.
- As User A, note a record id that belongs only to you (an order, note or profile row).
- Sign in as User B and request User A's id through your API or client (for example GET /api/.../{id}).
- 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.
- 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 waitlistVibe Security Weekly
One email a week with new failure patterns and how to fix them.
Free. Unsubscribe anytime. We'll never sell your email.