Cursor
Supabase RLS on a Cursor app
Cursor writes the repo on your machine. Visitors see the host you deployed to. A key in a local .env is invisible here. A key compiled into the deployed JavaScript, or returned at /.env, is not.
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.
The scan does not open the Cursor workspace, the chat, or git history on your laptop.
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 Cursor project?
No. The scan does not open the Cursor workspace, the chat, or git history on your laptop.
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.