Missing Supabase Row Level Security (RLS)
Supabase is the default database behind a huge share of vibe-coded apps. It ships with a publishable anon key that lives in your frontend by design. The safety of your data depends entirely on Row Level Security (RLS) policies, and AI builders frequently forget to add them. Without RLS, that public key can read your whole table.
What it looks like
Your app works. Users sign in, data loads. But the anon key in your JavaScript can query tables directly, and if a table has no RLS policy, it returns every row to anyone who asks, signed in or not.
This is not a Supabase bug. Tables you create through the Supabase dashboard now default to RLS on, but vibe-coding tools usually create tables by running raw SQL migrations, and those do not enable RLS unless the script explicitly says so. The generated scaffolding often never adds it.
Why it matters
Anyone who opens your app's network tab can copy the query and run it against your database. Whole tables of users, orders, or messages come back. In our own scans of vibe-coded apps, unprotected tables are one of the most common critical findings.
How ArgosX detects it
ArgosX probes your app's real database endpoints the way an anonymous visitor's browser could, and reports any table that returns rows without authorization. When sensitive fields are present, it is graded critical, with the evidence attached.
How to fix it
Turn on RLS for every table that holds user data, then add a policy for each access pattern.
- In the Supabase dashboard: Table editor, pick the table, enable Row Level Security.
- Add a policy so users only read their own rows, for example: auth.uid() = user_id.
- Repeat for insert, update, and delete. RLS defaults to deny, so an unpoliced action is blocked, which is the safe direction.
- Re-test: a good scan should now return nothing for the anonymous case.
Common questions
Is it safe to expose the Supabase anon key in my frontend?
The anon key is meant to be public. What makes it safe or unsafe is your Row Level Security policies. With correct RLS, the key can only reach what a given user is allowed to see. Without RLS, the same key can read entire tables.
Does enabling RLS break my app?
It can, if your app relied on unrestricted reads. That is the point: it forces you to declare who can see what. Add a policy for each legitimate access pattern and the app keeps working, safely.
Check your own app for this, free.
A free scan runs in minutes, no signup. Where it finds this, it proves it with the request and screenshot, not just a maybe. A human-verified pass is available when you want a person to confirm every finding.