Home / RLS / Bolt.new + Supabase security checklist

Supabase security · Bolt.new

Bolt.new + Supabase security checklist

01 Why Bolt apps need this

A Bolt.new app is usually a Vite frontend that calls Supabase from the browser. There's no backend in between checking who's asking, so every rule about who sees which rows has to live in your Row Level Security policies. If a table has RLS off, or a policy that's always true, the public anon key in your app opens it to anyone.

Two things to know about Vite: variables starting with VITE_ are bundled into the JavaScript every visitor downloads, and environment variables you set for a deploy (on Netlify, Vercel or elsewhere) follow the same rule. A VITE_ prefix on the wrong key is a leak.

02 Is the master key in your frontend?

The service_role key (or a new sb_secret_ key) bypasses every RLS policy. If it ships to the browser, anyone who opens your site can copy it and read or change your whole database. Builders put it there when it lands in a VITE_ variable or gets pasted into client code.

Scan your live app for it (free, paste the URL). Found one? Rotate it in the Supabase dashboard (Settings → API), move it to a server-only variable, redeploy and scan again.

.env

# fine in the browser: the URL and the anon / publishable key
VITE_SUPABASE_URL=https://xyz.supabase.co
VITE_SUPABASE_ANON_KEY=...  # or a sb_publishable_ key
# never with the VITE_ prefix: it would ship to every visitor
SUPABASE_SERVICE_ROLE_KEY=...

03 Which tables can anyone read?

Your anon key is public by design; RLS is the only thing between it and your data. Run this in the Supabase SQL editor:

check.sql

select c.relname,
       has_table_privilege('anon', c.oid, 'select') as anon_can_read,
       c.relrowsecurity as rls_on
from pg_class c join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
order by 1;

Any row with anon_can_read = true and rls_on = false is public: close it.

04 RLS is on, but is it doing anything?

"RLS enabled" isn't the same as "data protected". A policy that is always true lets everyone in, and generated code often contains one. List them:

check.sql

select tablename, policyname, cmd, roles, qual, with_check
from pg_policies
where schemaname = 'public'
  and (qual = 'true' or with_check = 'true')
order by 1, 2;

Keep a row only if that table is public on purpose (a catalog, a status page). Otherwise replace it with a policy scoped to the user. The RLS policy generator writes one per operation, tested.

05 Functions anyone can call

A security definer function runs as its owner and skips RLS. In the public schema it's also an API endpoint (/rest/v1/rpc/…). List the ones a signed-out visitor can execute:

check.sql

select p.proname
from pg_proc p join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
  and p.prosecdef
  and has_function_privilege('anon', p.oid, 'execute')
order by 1;

For each one: is it meant to be public? If not, revoke execute on function public.name(...) from public, anon; or move it to a schema the API doesn't expose.

06 Prove it as a stranger

The dashboard and the SQL editor bypass RLS, so they always look fine. Test the way an attacker would: open your app in a private window, signed out, copy the anon key from the network tab, and request a private table:

terminal

curl "$SUPABASE_URL/rest/v1/orders?select=*" -H "apikey: $ANON_KEY"
# rows from other users → the policy is broken; [] → good

Then keep it fixed: npx airlock-rls in CI fails the build when a table ships without RLS or with an always-true policy, whoever (or whatever) wrote the migration.

FAQ