Can a stranger read the tables behind your app?
Your app ships the address of its Supabase project and the public key inside its own JavaScript, as intended. We use them to ask for exactly one row, the way any visitor could, and tell you whether anything came back.
PASTE YOUR SITE'S ADDRESSThe public key is not a secret, it belongs in the browser. What limits access is Row Level Security: one rule per table that decides who may see which row. On a newly created table it is off until somebody switches it on.
That is where the AI loses the thread. It creates tables, writes the app around them, everything works, and the rules stay off. It does not look broken. It only shows up when someone goes looking, and bots go looking constantly. The same pattern sits behind CVE-2025-48757.
In our sample of public Lovable sites, 11 of the 38 sites with a detectable database had at least one table readable without a login. Together those tables reported more than 5,000 rows.
We read the table names out of the JavaScript your own page serves. Then, with the public key, we ask each table for exactly one row and read the total the database itself reports back in the response header. Nothing else happens: no writing, no deleting, no login, no password attempt, no second page.
If nothing comes back we say so plainly: an empty table and a protected table look identical from outside. We do not then claim everything is safe, only that nothing was readable from outside.
If an open table carries columns that look like personal data, we report that separately, because a duty to report under Art. 33 GDPR can come into play.
Switch Row Level Security on for every table in the public schema and add a rule that only releases a user’s own rows. The paid report gives you the text to paste into your builder, and you can re-check straight away to see whether it took.
Second: search the JavaScript you ship for the service_role key. If that is in the browser, no rule helps any more and it has to be rotated immediately. We check for that too.
Your Supabase table answers to anyone who asks, no login needed. That is your users' data, readable by strangers. We ask once, read-only, and report what came back.
A readable table contains fields like email, phone or password hashes. That is the kind of leak that gets reported to the authorities.
Sign-up is open and "confirm email" is off, so a script can create thousands of accounts, including with other people's addresses.
No, it belongs there. It only becomes dangerous when the tables behind it have no rules, or when the service_role key is shipped by accident. That one bypasses everything.
We request one row per table to establish whether anything answers at all. What the report shows is masked and visible only to you, and the content is not stored. The study contains no content, no table names and no addresses.
Because an empty table looks exactly like a protected one from outside. We say we cannot tell the difference rather than sell you a false sense of safety.
Same pattern, different mechanism: there it is the security rules. We check Firebase as well, also read-only.
Everything legal on this page is general information with a pointer to the rule it comes from. Deckproof does not assess your individual case and does not give legal advice.