← Back to the blog
Security

Your Lovable app may be showing data to anyone. Here is how to check

An analysis of 159,000 projects built with Lovable found thousands of apps handing database records to visitors who never logged in. The cause is usually a Supabase setting you can check in minutes.

Database cylinder with an open padlock in dark lines on a light background, beside the glass form with a blue core

Building an app with Lovable in an afternoon is now routine. Few people check who can read the data that app stores.

On 2 November, the German business daily Handelsblatt published an analysis carried out with the security firm Crissy Field on apps built with Lovable. The numbers are hard to ignore.

What the analysis found

According to coverage of the analysis, the researchers collected 159,041 projects published with Lovable. Of those, 34,545 used Supabase as their database.

  • In 24,664 apps, database records appeared as soon as the page loaded, with no login.
  • In 7,403 of them, there were tables holding user email addresses.
  • The examples cited include passport numbers, chat messages and customer lists.

The researchers add their own caveats. Some of that data may be public on purpose, such as a product catalogue, and they could not tell whether anyone misused it. Even so, the pattern is clear, and this was not a breach of Lovable itself. The problem lies in how each app is configured.

Why it happens

Every Supabase app ships a public key to the browser. It is designed to be visible, and protection depends on the database rules known as RLS (Row Level Security).

The Supabase documentation warns that an exposed table without RLS can be read and changed by anyone with access to it. When the AI assistant creates a table and forgets to turn RLS on, or turns it on without well-designed rules, the public key opens the door.

Two paths from an app in the browser to the database, where the table without RLS returns data to any visitor and the table with RLS shows each user only their own records

How to check your app today

You do not need to be a developer for the first check:

  1. Open the Supabase dashboard and look at the list of tables. Tables flagged with RLS disabled are the first warning sign.
  2. Run Supabase's Security Advisor, which points out exposed tables and functions.
  3. Turn RLS on for every table and write rules so each user sees only their own data.
  4. Check the files in Storage. Public buckets holding customer documents or photos are another common leak.
  5. Search your site's code for the secret key. It bypasses every rule and must never reach the browser.
  6. Test with a second account. Log in as another user and try to open the first user's data.

If the app stores customer data and something was open, bring in whoever handles legal matters. Many data protection laws require notifying the authority and the people affected. Under the GDPR, for example, the deadline is 72 hours when the breach puts people at risk.

Fix or migrate?

In most cases, turning RLS on and writing good rules solves it. Migration makes sense once the app has outgrown the prototype, stores sensitive data, or a large customer asks for a security questionnaire, a data processing agreement or AWS hosting.

In our migration of Lovable apps to AWS or Google Cloud, the first stage is exactly this review of database, logins and permissions. You get a written plan before anything changes, and the code and accounts stay in your company's name.