v0
Supabase RLS on a v0 app
v0 generates UI you then deploy, often on Vercel. The scan starts at the deployed URL. It sees the shipped page, not the v0 chat that produced the components.
How a public bundle relates to Row Level Security, which this scan does not read.
What the scan can see
If a service_role JWT is in the page or a same-origin script, the scan flags it. That key bypasses Row Level Security, so it must not ship to the browser. An anon JWT is recorded as informational, because the client is supposed to have it.
What it does not do
This scan does not connect to Postgres, list tables, or read RLS policies. A quiet result does not mean RLS is on. The ownership-verified RLS check is listed on the report as coming soon and is not run.
A component that was generated but never deployed is not part of the check.
What to do next
Rotate a leaked service_role key. Review policies in the Supabase SQL editor yourself. Private tables should deny access unless the signed-in user is the one you expect. This product will not run those queries for you.
Questions
Does this open my v0 project?
No. A component that was generated but never deployed is not part of the check.
Can the scan prove supabase rls is fully fixed?
This scan does not connect to Postgres, list tables, or read RLS policies. A quiet result does not mean RLS is on. The ownership-verified RLS check is listed on the report as coming soon and is not run.
What should I do if the scan finds it?
Rotate a leaked service_role key. Review policies in the Supabase SQL editor yourself. Private tables should deny access unless the signed-in user is the one you expect. This product will not run those queries for you.
Scan a URL you own
The same free check as the homepage. You confirm the app is yours before it runs.