On October 30, 2026, Supabase stops automatically exposing database tables to the public API for existing projects. Two things can happen to your Lovable, Bolt, or Replit app: a feature that quietly depended on that default can break, or — if your database has been readable by strangers all along — it keeps leaking, because already-exposed tables are grandfathered and the deadline won’t fix them. The only way to know which applies to you is to check the live app.
If your app reads a table through Supabase’s API that you never explicitly opted in, and it isn’t already exposed today, that access can stop on October 30. A page goes blank, a list won’t load. Annoying, visible, and fixable — but a nasty surprise if the first you hear of it is a user complaint.
If your database has been readable by the public this whole time, the deadline does not save you — already-exposed tables are grandfathered. Your app keeps working on October 31, and your users’ data keeps being readable by anyone. “It didn’t break” feels like relief and is actually the worse outcome.
It’s real — Supabase is notifying active projects and its Security Advisor flags the affected tables. But that email only tells you which tables the API-exposure change touches. It does not tell you whether your app has been leaking data to the public. For that you have to test the live app from the outside — which is exactly what the free check does.
Supabase is finishing its 'Secure by Default' rollout. New projects created since May 30, 2026 already work this way; on October 30, 2026 it extends to existing projects. The change: tables in your public schema are no longer automatically exposed through the data (REST/GraphQL) API. Going forward you have to explicitly opt a table in before the API will serve it. It's a good change — it closes the exact default that has been leaking AI-built apps' data all year.
It can, in one specific way: if your app quietly relies on a table being reachable through the data API without you ever setting that up on purpose, and that table isn't already exposed today, access to it can stop — and a feature that reads it breaks. The practical answer is to check now, before the date, so any table your app genuinely needs is opted in deliberately rather than discovered when a page goes blank.
That's the trap. Tables that are already exposed today stay exposed after October 30 — the change doesn't retroactively lock them down. So if your database has been readable by the public this whole time (the #1 flaw in AI-built apps), October 30 does NOT fix it for you. Your app won't break, but it was leaking before the date and it will keep leaking after. 'My app still works on the 31st' is not the same as 'my app is safe.'
Supabase's Security Advisor flags the tables the change affects, and Supabase is emailing active projects ahead of the deadline. If you got one, it's a real, non-urgent heads-up — not a phishing attempt — telling you some tables need a decision. It does not tell you whether your app has been leaking; it only flags what the API-exposure change touches. To know if your data is actually reachable by strangers, you have to test the live app from the outside.
Run a free external check on your live app. It tests, from the outside, whether your database is readable without a login right now. Clean result: the change is just good hygiene for you, opt-in any tables you need and move on. Exposed result: you've been leaking regardless of the date, and grandfathering means October 30 won't save you — that needs a fix (database rules / RLS) now.
Three things. (1) Check whether your database is exposed today — if it is, fix the rules now; the deadline won't. (2) Before October 30, make sure any table your app genuinely reads through the API is opted in on purpose, so nothing breaks. (3) After the change, keep an eye out: the next feature your builder ships can re-open a table or re-expose data, which is exactly what monitoring is for.
Related: how to fix Supabase row-level security on a Lovable app · check if your app is hackable.
One check tells you whether your database is exposed today — the part the deadline won’t fix — and gives you the fix for what it finds.