mediumLogins, sessions and access

Table Created Without Row Level Security

This migration creates a table but does not turn on row-level security for it.

Why it matters

Until RLS is enabled, a table in Supabase's public schema is open to anyone holding the anon key, which is everyone who loads your site. AI tools write the create table statement and stop there. The gap is easy to miss because everything works.

What it looks like

This is the shape of code that triggers the rule. AI tools produce it because it works, and nothing tells them it is unsafe.

Create table with no RLS
create table public.orders (
  id uuid primary key default gen_random_uuid(),
  user_id uuid references auth.users(id),
  total numeric
);

The smallest fix

minimal patch
-- Right after create table:
alter table public.orders enable row level security;

create policy "users read own orders" on public.orders
  for select to authenticated using (user_id = auth.uid());

Let your AI tool fix it

When the scanner finds this in your project, it fills in the file and line for you. This is the prompt it gives you to paste into Claude Code, Cursor or whatever you use.

The migration [the file] creates a table without enabling row-level security. For each table it creates, add `alter table ... enable row level security;` and at least one policy scoped to auth.uid() for the authenticated role. Ask me which tables, if any, are meant to be public and give those a select-only policy.

How to check the fix worked

1. Apply the migration, then in Supabase > Table Editor confirm each new
   table shows RLS enabled.
2. From the browser console with the anon key, select from the table
   while signed out. It must return nothing.

Further reading