Can strangers read your Lovable app's data without logging in?
Researchers looked at thousands of public Lovable apps and found many that hand database records to anyone, no login needed. Here is what that means in plain words, and a quick way to check your own app.
Only scan apps you own or have permission to scan.
What the study found
In early November 2026, the German security firm Crissy Field published a study of 159,041 public Lovable projects found in the Common Crawl web archive (published between December 2025 and September 2026). 34,545 of them used Supabase as their database.
On 24,664 of those sites, Supabase records were already visible when the page loaded, with no login. That alone is not always a problem, because some data is meant to be public. But with further read-only requests using the same public key the page gives every browser, the researchers found records with email addresses in 10,560 tables on 7,403 sites (about 30 percent).
The researchers are careful about what that means: it is not a confirmed breach rate, some emails may be public contact addresses or test data, and the sample does not stand for every Lovable app. Nobody hacked Lovable. The cause was missing or loose database access rules, table by table.
Why this happens: Lovable apps usually talk to Supabase straight from the browser with the public anon key. That key is meant to be public. What keeps private rows private is Row Level Security (RLS) and careful grants. If a table has RLS off, or a policy that is too loose, anyone who opens your site can read it. New tables added by an AI prompt can also ship without a matching rule.
What the free scan checks
- 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.
- Supabase service_role key
A Supabase service_role key in your client code is flagged as critical. That key skips Row Level Security entirely.
- 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.
Check your own app in 5 minutes
- Open it signed out. Use a private window and visit your live app the way a stranger would. Look for names, emails, orders, chats or uploads before you log in.
- Turn on RLS everywhere. In the Supabase dashboard, make sure Row Level Security is enabled on every table that holds user or business data.
- Write policies that match real users. For user-owned rows, only the signed-in user whose auth.uid() matches the row's user_id should read or change it.
- Fix the Security Advisor list. Open Advisors in Supabase and fix every warning about missing RLS or overly broad policies.
- Grant narrowly. Never use GRANT ALL to silence a permission error. Grant only what each role needs (see the Oct 30 Supabase change below).
- Recheck after every prompt. Any prompt that adds a table, form or upload can add a table without a rule. Check again after each one.
- Get an outside view. Run the free scan above. Tick the owner box only if you own the Supabase project.
FAQ
- Is my Lovable app affected?
- We can't tell from the study, because it does not name apps. If your app stores user data in Supabase, the signed-out check above takes five minutes.
- Is the anon key a leak?
- No. The anon key is public by design. Grants and Row Level Security are what protect your data, not hiding the key.
- What does the owner box do?
- If you own the Supabase project and tick it, we ask 15 common table names (like users, profiles, orders) for 1 row with your public anon key. Row contents are never stored or shown. Without the tick we only read your public page and scripts.
- What if emails were exposed?
- Tighten access first (RLS, policies, narrow grants), rotate any exposed secrets, review your logs, and consider telling affected users. This is general hygiene, not legal advice.
- 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.
- Does it attack my site?
- No. It only makes ordinary read requests, sends no exploit payloads, and never logs in or submits forms.
- 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.