Supabase RLS errors in AI-built apps, decoded

Supabase's docs say that once RLS is enabled, no data is accessible through the API with a publishable key until you create policies. A read with no matching policy doesn't fail. It returns zero rows.

So the table has rows in the dashboard, and the app shows nothing. Add a select policy. This one lets each signed-in user read their own rows:

create policy "Users can read their own rows" on todos for select to authenticated using ((select auth.uid()) = user_id);

If the page should be public, such as a list of published posts, write the policy for the anon role and limit it to the rows that are meant to be public.

The same silent pattern hits saves. Supabase data not saving, no error covers that side.

This one does show an error. The insert has no policy that allows it, or the new row fails the policy's with check rule, often because user_id isn't sent.

It has its own guide with five causes and the SQL for each: New row violates row-level security policy in Supabase.

You change a record, the app says saved, and the old value is back after a refresh. Or a delete button runs and the row stays.

Supabase doesn't raise an error when a policy filters out every row an update or delete targets. Zero rows change and the request succeeds.

Each action needs its own policy. An update also needs a select policy: Supabase's docs say that without a SELECT policy, the UPDATE operation will not work as expected. Add both:

create policy "Users can update their own rows" on todos for update to authenticated using ((select auth.uid()) = user_id) with check ((select auth.uid()) = user_id);

create policy "Users can delete their own rows" on todos for delete to authenticated using ((select auth.uid()) = user_id);

This error, code 42P17, shows up in apps with teams, workspaces or shared projects. A policy on a table such as members checks membership by reading the members table. Reading it runs the same policy again, and Postgres stops the loop.

Supabase's docs say to break the cycle with a security definer function. The function reads the table as its owner, so the policy doesn't run again inside it. Put it in a schema the API doesn't expose:

create schema if not exists private;
create function private.is_team_member(team uuid) returns boolean
language sql security definer set search_path = ''
as $$ select exists (select 1 from public.members where team_id = team and user_id = (select auth.uid())); $$;

create policy "Members can read their team's rows" on members for select to authenticated using (private.is_team_member(team_id));

Delete the old policy that read the members table directly, then test as a member and as a non-member.

Code 42501 with permission denied means the role has no grant on the table. Supabase's docs say a missing grant raises 42501 before any policy is checked, so a perfect policy still fails.

Grant the actions your app uses to the role that needs them, usually authenticated. Step 5 of New row violates row-level security policy in Supabase has the line.

Server code, edge functions and API routes make their own Supabase client. If that client doesn't carry the signed-in user's token, the database sees a signed-out visitor, and every policy written for authenticated filters the rows away.

In Next.js, build the server client with the cookie helpers from @supabase/ssr. In an edge function, pass the Authorization header from the request into the client. Then auth.uid() returns the right user again.

Supabase's docs say a secret key is for administrative tasks that need to bypass RLS. Keep it in server code only. Never use it to make a user-facing page work.

Turning RLS off makes the error go away. Your publishable key sits in the site's code, and Supabase's docs say anyone can read it and it only reaches what Row Level Security allows. With RLS off on a table, any visitor with that key can read and change it.

Putting the service_role or secret key in the browser also makes the error go away. Supabase's docs say a secret key bypasses every Row Level Security policy and should never go in a browser, a shipped application or source control. If one leaked, delete it in the dashboard and make a new one.

If an AI builder offered either fix, undo it before launch. Is my vibe-coded app secure? Seven checks before launch has the other checks.