Your vibe-coded app's database rules are about to change. Is it still safe?
On October 30, 2026, Supabase stops auto-exposing new public tables to the Data API in existing projects — every new table needs an explicit GRANT first (Supabase changelog). VibeShield gives you a free passive check and copy-paste fix prompts. The founding plan ($19/mo founding price) adds weekly re-checks of your Lovable, Bolt or Supabase app and emailed fix prompts — deeper checks are coming.
Cancel anytime. Not ready to pay? Join the free waitlist.
What changes on October 30, 2026
Before
With default settings, every new table in public was automatically granted to anon, authenticated and service_role — instantly reachable through supabase-js / REST / GraphQL, protected only if someone remembered RLS.
After
New tables return 42501 permission denied through the Data API until you GRANT access — including to service_role if your server or Edge Functions use it. Existing tables keep their current grants — including any that were exposed without RLS.
Only the Data API (supabase-js, REST, GraphQL) is affected. Apps that talk to Postgres over a direct connection (psql, an ORM, a server with a connection string) are not.
Why vibe-coded apps are exposed
- AI tools create tables without a human reviewing the diff. That's Supabase's own reason for the change: agents, CLI scripts and AI platforms now create tables, and the old default grants exposed every new table "including tables a developer forgot to protect" (changelog).
- The quickest "fix" can be worse than the bug. When the new permission errors hit, the easiest copy-paste is a bulk
grant … on all tables in schema public …— which re-opens every table, including the unprotected ones. - Secrets leak into bundles.
service_rolekeys, Stripe and OpenAI secrets can end up inVITE_/NEXT_PUBLIC_env vars and get shipped to every visitor. - Old tables don't get fixed automatically. The change only protects new tables. Whatever was exposed before stays exposed.
What VibeShield does
Weekly re-checks (founding plan)
We re-run the passive check on your app every Monday and email you the report: leaked keys in your page and JS bundles (including Supabase service_role / secret keys), missing security headers and CORS mistakes — what a passive check can actually see. Deeper checks are coming.
Emailed fix prompts
Paste-ready prompts for Lovable, Bolt or Cursor that grant per table and enable RLS — never bulk grants.
Plain-English report
What's critical, what's fine by design (like your anon key), and what to do next.
Check my app — free
Our free passive check reads only your page HTML and same-origin JS bundles. No database probing, no logins, no writes. Secret values are never shown or stored.
Guides
Is my Supabase anon key leaked?
What the public anon/publishable key really exposes, how to tell it apart from a secret key, and how to check grants + RLS.
Supabase 42501 permission denied after Oct 30
The safe per-table fix (grant + RLS + policies) — and why to skip the bulk rollback.
Founding plan
- Your first report by email within minutes of subscribing
- A passive re-check every Monday (page HTML + same-origin JS bundles), emailed with what's new, fixed and still open
- Copy-paste fix prompts for Lovable / Bolt / Cursor / Supabase in every report
- Change the checked app URL anytime from the link in any report
- Deeper checks are coming — included as they ship
- Founding price locked while you stay subscribed · cancel anytime
Billed monthly via Stripe. Cancel anytime from the billing portal; you keep access to the end of the paid period. The check is passive — it never logs in, probes your database or writes data.
Not ready yet? Join the free waitlist
No payment. We'll email you about launch news and founding pricing.