New Supabase table says "permission denied"? Here's the safe fix.
Supabase changed how new tables are exposed. Your app isn't broken, it just needs a small, careful grant. Here's what changed and how to fix it without opening your data to everyone.
Only scan apps you own or have permission to scan.
What changed
Until recently, every new table in the public schema was automatically reachable by the anon and authenticated roles through the Data API. Supabase rolled out a change, applied to existing projects starting Oct 30, 2026, so new tables are not exposed until you grant access. Tables you already had keep their grants. Source: Supabase changelog, supabase.com/changelog/45329.
Symptoms: your app or AI builder adds a new table and requests start failing with "permission denied for table your_table" (code 42501). It often works in the SQL editor but not from your app, because the editor runs as a different role.
Why not grant everything: granting all actions to all roles makes the error go away, and also lets anyone with your public anon key (which is in your frontend) do anything Row Level Security doesn't stop. If RLS is off or a policy is too loose, your data can be readable or changeable by strangers. The error is a safety net. Fix it narrowly.
Checklist for every new table: only the grants each role needs, RLS enabled, policies that limit rows to the right user, tested logged out and as a second user, service_role key only on the server, and a run of Supabase's Security Advisor.
What the free scan checks
- Supabase service_role key
A Supabase service_role key in your client code is flagged as critical. That key skips Row Level Security entirely.
- Open tables (owner opt-in)
If you use Supabase, tick the extra box and we ask 15 common table names (like users, profiles, orders) for 1 row using your public anon key. Row contents are never stored or shown.
- Leaked keys in your frontend
Your page HTML and up to 15 of your own JavaScript files are checked for Stripe live secret and restricted keys, OpenAI, Anthropic, AWS, GitHub, Slack and Resend keys, Google API keys and private key blocks. Anything found is masked in the report.
- Files left on the server
Things like /.env, /.env.local, /.env.production, /.git/config, .npmrc, docker-compose.yml, backup files, and package.json or lockfiles.
The safe fix
- Decide who uses the table. Signed-out visitors (anon), signed-in users (authenticated), or only your server.
- Grant narrowly. Grant only the actions each role needs. A read-only public list needs select for anon, not insert or delete.
- Keep RLS on. Keep Row Level Security enabled on the table and add policies so each user sees only their own rows.
- Make it a habit. Treat grant, RLS and policies as one step every time you add a table.
- Check the live app. Run the free scan to see what your live app shows to a stranger.
FAQ
- Do my existing tables break?
- Per Supabase, no. They keep their current grants.
- Does this replace RLS?
- No. Grants decide if a role can touch a table at all; RLS decides which rows.
- Does VibePatrol read my grants?
- No. It checks from the outside: a service_role key in your frontend and, with your opt-in, whether common tables can be read logged out. Also use Supabase's Security Advisor.
- Do I need to sign up?
- No. Paste your link, confirm it's your app (or you have permission), and run it. Adding your email is optional and shows the risk breakdown and one problem by name.
- What does it cost?
- The scan and your score are free. The full list of findings with a fix for each is a one-time $9, or $29 for a pack of 10 reports.
- What doesn't it check?
- Pages behind a login, third-party scripts, your server code and your database policies directly. A good score is not a guarantee of security.