DEV Community: LeakPatrol

Supabase "permission denied for table" since 30 October? Don't let your AI fix it with GRANT ALL

LeakPatrol — Wed, 04 Nov 2026 21:10:14 +0000

Since 30 October 2026, new Supabase tables aren't granted to the Data API automatically. So the first time your app touches a new table, supabase-js returns:

code: "42501"
message: "permission denied for table notes"

It's not a bug. Your app talks to Supabase as anon (logged out) or authenticated (signed in), and a role needs a Postgres GRANT before it can touch a table at all. Older tables got those grants for free. New ones don't.

The fix is one line. The problem is which line your AI tool picks.

Two errors, same code

Both of these come back as 42501, but they mean different things:

Message	What's wrong	Fix
`permission denied for table …`	No grant for that role	Add a narrow `GRANT`
`new row violates row-level security policy …`	RLS blocked this row	Add the missing policy

If you paste either one into Lovable, Bolt or Cursor, check which one it is first. They need different fixes.

The safe fix for "permission denied"

RLS and a policy first, then grant only what the app needs, only to the role that needs it:

alter table public.notes enable row level security;

create policy "Users manage their own notes"
on public.notes for all
to authenticated
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

grant select, insert, update, delete on public.notes to authenticated;

For data everyone may read but nobody may change from the browser (products, blog posts):

alter table public.products enable row level security;

create policy "Anyone can read products"
on public.products for select
using (true);

grant select on public.products to anon, authenticated;

The fixes that make the error go away and open your table

Your anon key is in your app's JavaScript, so anyone can use it. Watch for these:

grant all on public.notes to anon: logged-out visitors get insert, update, delete and TRUNCATE, which RLS doesn't cover at all.
Granting to anon on user data. Logged-out visitors never need your users' rows.
Granting before RLS is on. Until the policy exists, every row is public. If the AI forgets the policy, it stays that way.
disable row level security or using (true) on user data.
The service_role key in the frontend. It skips RLS completely.

A prompt that works

My Supabase table is giving error 42501 "permission denied for table".
Fix it safely:
1. Enable Row Level Security on the table first, with policies so users
   only read and change their own rows (auth.uid() = user_id), including
   WITH CHECK on insert and update.
2. Then grant only the needed privileges (select, insert, update, delete),
   only to the authenticated role. Do not grant to anon unless the data is
   meant to be public, and never use GRANT ALL.
3. Do not disable RLS, do not use using (true) on user data, and do not
   use the service_role key in the frontend.
Show me the SQL before running it.

The last line matters most. Read the SQL before you click run.

Your old tables didn't change

The 30 October change only affects new tables. A table that was readable with your anon key last week still is. Two queries to check:

select tablename, rowsecurity from pg_tables where schemaname = 'public';

select table_name, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
group by table_name;

Any table with rowsecurity = false that anon can select from is readable by anyone.

Checking a live app

I build LeakPatrol, a free read-only scanner for apps built with Lovable, Bolt, v0 and Cursor. It checks your live site from the outside for leaked keys and public files in about a minute. There's also a free RLS policy generator that writes the grants and policies for common table types.

Full guide with an FAQ: Supabase error 42501, the safe fix. And if you're seeing the other one, here's the RLS error guide.

Your Supabase users can probably give themselves your paid plan. Here's the 30-second test

LeakPatrol — Sun, 25 Oct 2026 20:52:33 +0000

A lot of apps built with Lovable, Bolt or Cursor handle "upgrade to Pro" with one line in the browser:

await supabase.from("profiles").update({ is_pro: true }).eq("id", user.id);

If that line works for your code, it works for anyone. Open DevTools, run the same thing in the console, and the paid plan is theirs. Same for plan, credits, role or trial_ends_at.

Why RLS doesn't stop it

The usual policy on a profiles table is "users can update their own row":

create policy "Users can update own profile"
on public.profiles for update
using (auth.uid() = id);

That policy decides which rows a user may change. It says nothing about which columns. If billing columns live on that row, the user can change those too.

Deleting the update call from your frontend doesn't fix it either. The policy still allows the request, and anyone can write it by hand with your public anon key and their own login.

The 30-second test (on your own app)

Log in as a normal free user.
Open DevTools → Console and run:

await supabase.from("profiles")
  .update({ is_pro: true })
  .eq("id", (await supabase.auth.getUser()).data.user.id);

Reload. If you're Pro now, so is anyone who tries.

Use your own table and column names. Only test apps you own.

Fix 1: grant updates per column

Postgres can grant UPDATE on specific columns. RLS still picks the rows; the grant picks the columns.

revoke update on table public.profiles from anon, authenticated;
grant update (full_name, avatar_url) on table public.profiles to authenticated;

List every column users should be able to edit. If users create their own profile row, do the same for insert, or someone can sign up with is_pro = true.

Fix 2: a trigger that guards billing columns

If you'd rather not touch grants:

create or replace function public.protect_billing_columns()
returns trigger language plpgsql as $$
begin
  if (new.is_pro is distinct from old.is_pro or new.plan is distinct from old.plan)
     and coalesce(auth.role(), '') <> 'service_role' then
    raise exception 'billing columns can only be changed by the server';
  end if;
  return new;
end $$;

create trigger protect_billing before update on public.profiles
for each row execute function public.protect_billing_columns();

Fix 3 (cleanest): billing gets its own table

Put subscriptions or credits in a separate table with a select policy for the owner and no insert, update or delete policies. Only your payment webhook writes to it, from an Edge Function using the service_role key, which stays a server secret.

Only the webhook sets the plan

Your Stripe or Lemon Squeezy webhook should verify the signature and then set the plan on the server. Don't set it from the checkout "thank you" page: anyone can open that URL without paying.

If you build with an AI tool, this prompt works well in Lovable, Bolt or Cursor:

Users must not be able to change is_pro, plan or credits. Only the payment webhook, in an Edge Function that verifies the signature and uses the service role key, may set them. Remove all frontend code that writes these columns, revoke UPDATE on profiles from authenticated and grant it back only for the columns users may edit. Do not turn off RLS.

The last sentence matters. When the new rules break something, AI tools like to "fix" it by disabling RLS.

Checking a live app

I build LeakPatrol, a free scanner for AI-built apps. It now reads the JavaScript your live site loads and flags code that writes paid columns (is_pro, premium, plan, credits…) straight from the browser, along with leaked keys and readable Supabase tables. It can't see your policies, so run the console test above as well.

The full guide, with an FAQ, is on our site.

Are VITE_ environment variables secret? No, and here's how keys leak from Lovable and Bolt apps

LeakPatrol — Sat, 24 Oct 2026 08:38:25 +0000

Short answer: no. In a Vite app, every environment variable that starts with VITE_ is written into your JavaScript bundle at build time. That bundle is downloaded by every visitor, so anyone can read the value in DevTools.

The same is true of NEXT_PUBLIC_ in Next.js and REACT_APP_ in Create React App.

Why the prefix exists

Vite hides variables without the VITE_ prefix from your frontend code on purpose. The prefix is how you tell Vite "this value is safe to publish".

Here's how secret keys usually end up public in AI-built apps:

The AI tool writes import.meta.env.OPENAI_API_KEY.
It's undefined in the browser, so the feature breaks.
The "fix" is to rename it to VITE_OPENAI_API_KEY.
The feature works, and the key now ships to every visitor.

Lovable, Bolt and most Cursor-built frontends are Vite apps, so this comes up a lot.

Fine in a `VITE_` variable

Your Supabase URL and anon (or sb_publishable_) key, as long as Row Level Security is on for every table
Stripe publishable keys (pk_live_, pk_test_)
Firebase config and Google Maps keys restricted to your domain
Analytics IDs (PostHog phc_, Sentry DSNs)

Never in a `VITE_` variable

AI keys: OpenAI (sk-proj-), Anthropic (sk-ant-), Groq, Replicate
Stripe secret keys (sk_live_) and webhook secrets (whsec_)
The Supabase service_role or sb_secret_ key, which bypasses RLS entirely
Email API keys (Resend re_, SendGrid SG.), AWS keys, database URLs with a password

Not sure which kind a key is? I made a free key checker that tells you what a key is and whether it's allowed in the browser. It runs entirely client-side, so the key never leaves the page.

How to move a key out of the frontend

Create a server-side function: a Supabase Edge Function, a Netlify or Vercel function, or an API route.
Store the key as a server secret with no VITE_ prefix, for example supabase secrets set OPENAI_API_KEY=....
Call your function from the frontend instead of the provider. Check the user is logged in inside the function, so strangers can't use it as a free proxy.
Rotate the old key. It's in every copy of your old bundle, including CDN and browser caches.

A prompt that works in Lovable, Bolt or Cursor:

Move every call that uses a secret API key out of the frontend into a
Supabase Edge Function that reads the key from Supabase secrets. Remove
the VITE_ variable for it and call the function instead. Only allow
logged-in users to call it. Don't print any keys in your reply.

Check what your live site actually ships

Your .env file isn't what matters. What matters is what ended up in the built JavaScript. Two ways to check:

Open your live site → DevTools → Sources → search all files (Cmd/Ctrl+Shift+F) for sk-, sk_live, service_role and sb_secret_. You should find nothing.
Or paste your URL into LeakPatrol, a free read-only scanner I built. It reads every script your site loads, lists any secret keys (masked), and also checks for public .env files, source maps and missing headers.

The full version of this guide, with a FAQ, is here.

Supabase's October 30 change: what it fixes for your app's security, and what it doesn't

LeakPatrol — Tue, 20 Oct 2026 20:10:44 +0000

On 30 October 2026, Supabase changes how new tables are exposed in existing projects. It's a good security change, but it's easy to misread as "my database is now safe". It isn't: tables you already have keep exactly the access they have today.

What's changing

Until now, every table created in the public schema was automatically granted to the anon, authenticated and service_role roles, so the Data API (REST and GraphQL, which supabase-js uses) could read and write it straight away. Row Level Security was the only thing standing in the way.

From 30 October, new tables in public won't get those grants automatically. You have to opt each one in with a Postgres GRANT before your app can reach it through the Data API. New projects have worked this way since May, and the Supabase CLI switched for local development in June. (Supabase changelog)

What doesn't change

Existing tables keep their grants. If a table is readable by anyone today, it still will be on 31 October.
Row Level Security works the same. A table with RLS off, or with a using (true) policy, is just as open as before.
Direct database connections (an ORM or server using a connection string) aren't affected.

So the change stops new accidents. It doesn't fix the leaks that are already out there.

What might break

If your app (or your AI tool) creates new tables after 30 October through migrations or the SQL editor, those tables won't be reachable from the browser until you grant access. Expect a permission error from the Data API on a brand-new table.

The fix is to grant only what the app needs, and to switch RLS on at the same time:

alter table public.notes enable row level security;

grant select, insert, update, delete on public.notes to authenticated;

create policy "Users manage their own notes"
on public.notes for all
using (auth.uid() = user_id)
with check (auth.uid() = user_id);

Only grant to anon (logged-out visitors) if the table is meant to be public, like a product list, and then usually just select.

Watch out for AI tools "fixing" the error the wrong way. If you paste a permission error into Lovable, Bolt or Cursor, check it doesn't respond by granting everything to anon or turning RLS off. That would recreate exactly the problem this change is meant to prevent.

What to check before 30 October

Because existing tables keep their access, this is a good moment to audit them. In the SQL editor:

1. Which tables have RLS off:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

2. What logged-out visitors are allowed to do:

select table_name, string_agg(privilege_type, ', ') as privileges
from information_schema.role_table_grants
where grantee = 'anon' and table_schema = 'public'
group by table_name;

Any table that appears in the second list with RLS off in the first is readable (and often writable) by anyone who has your anon key, which is in your app's JavaScript.

3. Policies that let everyone through: look for using (true) in Authentication → Policies.

If you'd rather not do it by hand, LeakPatrol is a free read-only check for AI-built apps: leaked keys, public .env files and missing protections, with a plain-English fix and a copy-paste prompt for each.

Is your Supabase anon key safe in the frontend? Yes. Here's what isn't.

LeakPatrol — Sun, 18 Oct 2026 13:36:43 +0000

If you've built an app with Lovable, Bolt, v0 or Cursor on top of Supabase, you've probably opened DevTools, seen a long eyJ... key in your JavaScript, and felt your stomach drop.

Good news first: that key is supposed to be there. Here's what it actually does, and the four things that do leak data in AI-built Supabase apps.

The anon key is public by design

Supabase gives every project two kinds of key:

Key	Starts with	Where it belongs
anon / publishable	`eyJ...` (role `anon`) or `sb_publishable_`	The browser. Fine to ship.
service_role / secret	`eyJ...` (role `service_role`) or `sb_secret_`	Only on a server. Never in the browser.

The anon key just identifies your project. On its own it grants nothing: what someone can do with it is decided entirely by your Row Level Security (RLS) policies.

That's also the catch. The anon key is safe only if RLS is doing its job.

1. Tables with RLS turned off

With RLS off, anyone who copies your anon key out of your JavaScript can read, and often write, the whole table with a single request. No login needed.

Check every table in the SQL editor:

select tablename, rowsecurity
from pg_tables
where schemaname = 'public';

Anything showing false is open. Turn it on and add a policy that ties rows to their owner:

alter table public.profiles enable row level security;

create policy "Users read their own profile"
on public.profiles for select
using (auth.uid() = user_id);

Watch out for policies with using (true). They turn RLS on but let everyone through, which AI tools sometimes generate to "fix" a permissions error.

2. The service_role key in the browser

The service_role (or sb_secret_) key bypasses RLS completely. If it's in your frontend, every table is open no matter how good your policies are.

AI tools usually put it there by accident: a VITE_SUPABASE_SERVICE_ROLE_KEY or NEXT_PUBLIC_... variable, added to make an admin feature work. Anything prefixed VITE_, NEXT_PUBLIC_ or REACT_APP_ is bundled into the JavaScript every visitor downloads.

If you find it: rotate the key in Supabase (Settings → API) right away, then move the admin work into an Edge Function that reads the key from Supabase secrets.

3. Storage buckets

Storage has its own policies, separate from your table RLS, and they're easy to forget. A "public" bucket means anyone with a file's URL can download it. Fine for avatars, not for invoices, ID photos or exports.

In Storage, check which buckets are public, and give private ones policies on storage.objects, just like tables.

4. Views and functions that skip RLS

Two quieter ones:

Views run with their creator's rights by default, so a view over a protected table can expose it. On Postgres 15+, create them with with (security_invoker = on).
Functions marked SECURITY DEFINER also run with their owner's rights. If one is callable through the API, check it only returns what the caller should see.

The 2-minute check

Open your live app, then DevTools → Sources, and search for service_role, sb_secret_, sk- and sk_live. You should find none.
Run the SQL above. Every table should show true.
Look for using (true) in your policies.
Check which storage buckets are public.

If you'd rather not do it by hand, I built LeakPatrol, a free read-only check that looks for leaked keys, a public .env and missing security headers, and, once you prove you own the site, which Supabase tables can be read without logging in. Each finding comes with a prompt you can paste back into your AI tool to fix it.

The anon key was never the problem. What you've built around it is what counts.

DEV Community: LeakPatrol

Supabase "permission denied for table" since 30 October? Don't let your AI fix it with GRANT ALL

Two errors, same code

The safe fix for "permission denied"

The fixes that make the error go away and open your table

A prompt that works

Your old tables didn't change

Checking a live app

Your Supabase users can probably give themselves your paid plan. Here's the 30-second test

Why RLS doesn't stop it

The 30-second test (on your own app)

Fix 1: grant updates per column

Fix 2: a trigger that guards billing columns

Fix 3 (cleanest): billing gets its own table

Only the webhook sets the plan

Checking a live app

Are VITE_ environment variables secret? No, and here's how keys leak from Lovable and Bolt apps

Why the prefix exists

Fine in a VITE_ variable

Never in a VITE_ variable

How to move a key out of the frontend

Check what your live site actually ships

Supabase's October 30 change: what it fixes for your app's security, and what it doesn't

What's changing

What doesn't change

What might break

What to check before 30 October

Is your Supabase anon key safe in the frontend? Yes. Here's what isn't.

The anon key is public by design

1. Tables with RLS turned off

2. The service_role key in the browser

3. Storage buckets

4. Views and functions that skip RLS

The 2-minute check

Fine in a `VITE_` variable

Never in a `VITE_` variable