Lovable Supabase Security: Test Who Can Read Your Users’ Data

If your Lovable app uses Supabase, test its data access as a logged-out visitor and as two different users before adding real customer records. A working login screen proves that sign-in works. It does not prove that the database refuses requests for another person’s information.

The immediate reason to check is Crissy Field’s research into Lovable applications. The firm reports finding confidential records accessible without authentication. Its current page updates an analysis reported by Handelsblatt on November 2; it does not establish a new incident affecting every Lovable app.

The researchers also caution that their Common Crawl sample is not representative. Their 30% figure is the share of the 24,664 more closely examined websites from which email-bearing records were retrieved, not a confirmed leak rate. Those records could include public contact addresses or test data. I have not independently accessed the affected applications or verified their datasets.

Check authorization, not just the login page

Authentication establishes who a person is. Authorization decides what that person can read or change. An app can implement the first correctly and still fail the second.

For Supabase-backed apps, row-level security lets database policies restrict individual records. A policy can compare the requesting user’s identity with a record’s owner. Insert and update rules also need to constrain the resulting data, so a user cannot assign a record to an unauthorized owner. Updates additionally need a corresponding select policy.

That is different from filtering the page in JavaScript. Hiding another customer’s row after it has reached the browser is already too late. Your test needs to inspect the response delivered to the client, not only the cards your interface chooses to display.

For a team product, “only the owner” may itself be the wrong rule. Write down whether access belongs to an individual, a workspace member or a specific administrator. Otherwise you can fix a visible leak by breaking legitimate collaboration, or restore collaboration by granting far too much access.

A public Supabase key is not automatically a leaked secret

Supabase’s API key guide distinguishes publishable keys, including the older anon key, from elevated secret keys and the older service_role key. Publishable keys are intended for client applications. User authentication and database policies determine what requests using them can reach.

Elevated keys belong in controlled backend components, not browser bundles. They bypass row-level security, so a successful test performed with one does not demonstrate what an ordinary user can access. A backend using elevated credentials must enforce its own authorization before returning data.

Do not respond to a visible publishable key by merely renaming an environment variable or hiding the value in a different frontend file. First establish which kind of key it is and whether unauthorized requests can retrieve protected data. If an elevated credential has shipped publicly, treat that as a separate credential exposure requiring containment and rotation.

Use a small, synthetic access test

Run this only against your own authorized staging environment, with fake records and test accounts. Do not inspect other people’s apps or copy real customer data into a test fixture. The following is a suggested test design, not a test I have executed against Lovable.

Create two users, Alice and Bob, in different test tenants. Give each a private note containing a distinctive marker, such as ALICE-STAGING-ONLY and BOB-STAGING-ONLY. Keep any intentionally public data separate. Use isolated browser sessions so a leftover login does not invalidate the result.

Test identity	Alice’s private note	Bob’s private note
Logged-out visitor	Not readable	Not readable
Alice	Readable	Not readable
Bob	Not readable	Readable

Check both collection views and the direct record-reading route your own app uses. Inspect the actual response body: an empty page is not a pass if its network response contains the other marker. Conversely, an empty response for Alice’s own note is not a security success; it may mean you have blocked everyone.

Then repeat the boundary checks for writes using disposable records. Confirm that Alice cannot modify Bob’s note or change a record’s tenant assignment to gain access elsewhere. Verify the stored result afterward rather than assuming a disabled button prevented the operation. Add any intended shared-workspace case as a separate positive test.

Record the expected outcome, actual outcome and relevant request identity for each case. Redact credentials from test reports. This small matrix is more useful than a screenshot saying the dashboard loaded successfully.

Run Lovable’s scans, then verify the fix

Lovable’s security documentation says its Quick scan checks database access rules and runs during publishing. Deep scan examines application logic and permissions more broadly. The documentation explicitly warns that these tools do not guarantee complete security or replace a thorough review.

Review database policies and unresolved findings in the project’s security tools. After a change, repeat the same synthetic tests rather than replacing them with a more convenient success case. Keep the failing case as a regression test so a later generated feature cannot quietly reopen the same access path.

If a test reveals an exposure involving real users, stop routine feature work and contain the affected access path while preserving the evidence needed for investigation. Do not paste exposed records into an AI prompt to ask what happened. Involve someone qualified to assess the scope and the appropriate response.

A generated app is not ready for private data merely because it looks finished. The meaningful milestone is that authorized users can do their work and unauthorized users cannot obtain the underlying records.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams explain product behavior and engineering tradeoffs clearly, without turning limitations into marketing promises.

Book a 30-minute call