Skip to content
ShipSecurelySecurity reference
Menu

13 tools · 88 fixes · 22 incidents tracked · Updated Oct 13, 2026 · Sources: Supabase, GitHub, OWASP, Stripe + 9

Supabase

Supabase tables without row level security in Supabase

criticalUpdated Oct 12, 2026

Enable RLS, then add a policy that matches the real rule, usually "a signed-in user may access their own rows."

Fix for Supabase

Enable RLS, then add a policy that matches the real rule, usually "a signed-in user may access their own rows."

alter table public.notes enable row level security;

create policy "notes_select_own"
on public.notes
for select
to authenticated
using (auth.uid() = user_id);

create policy "notes_insert_own"
on public.notes
for insert
to authenticated
with check (auth.uid() = user_id);

create policy "notes_update_own"
on public.notes
for update
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

create policy "notes_delete_own"
on public.notes
for delete
to authenticated
using (auth.uid() = user_id);

Write separate policies for select, insert, update, and delete. An insert policy needs with check, not only using. Afterward, repeat the anonymous API call and confirm it returns nothing it should not.

Do not store a role or plan on auth.users raw user metadata and trust it inside a policy. Supabase documents that end users can change user_metadata through the client libraries. Put privileged flags in a table the user cannot update.

Views and materialized views need extra care. A view can bypass the underlying table's RLS unless it is created with security_invoker = on. Materialized views cannot use RLS. Do not expose those to the anon or authenticated roles if they contain private rows.

The five-minute check, the other platforms, and the agent prompt are on the full guide. More Supabase fixes are on the Supabase page.