Is your Lovable app secure? Supabase RLS checks before launch

A Lovable app with a Supabase back end is only as secure as its Row Level Security (RLS) policies. The browser talks to the database directly with a public key, and RLS is the rule that decides, row by row, what each visitor may read or change. Lovable scans for the most common mistakes, but its own documentation says the responsibility stays with you. This page explains how the pieces fit together and gives you a check-list, based on the official Supabase and Lovable documentation, consulted on 6 November 2026.

It goes deeper on the database than our general security checklist for a vibe-coded app, which covers the whole launch.

Why RLS is the whole security model

In a classic web application, the browser asks a server, the server checks who you are, then queries the database. Nothing reaches the database without going through code you control.

A Lovable app usually works differently. The front end calls Supabase straight from the browser, through an automatically generated API. To do that it ships a key inside the page. Supabase calls this the publishable key (the older name is anon key), and its API keys documentation describes it as safe to expose. Anyone can open the browser developer tools and copy it, along with your project address.

That is by design, and it is fine, on one condition: every table reachable through the API must have RLS turned on, with policies that match your rules. If a table has no RLS, anyone with the public key can read it and, depending on grants, write to it. There is no server in between to catch the mistake.

The same applies to apps on Lovable Cloud: the Lovable Cloud documentation says the built-in back end uses Supabase’s open-source foundation, so the same mechanics apply, even if you never open a Supabase dashboard.

What actually went wrong: the 2025 disclosure

This is not a theoretical risk. In 2025, a researcher disclosed that many Lovable-generated sites had tables readable or writable without logging in. It was registered as CVE-2025-48757, published on 30 May 2025, which describes insufficient RLS policies in Lovable through 15 April 2025. The record notes that Lovable disputes it, on the grounds that each customer is responsible for protecting the data of their application.

Both readings lead to the same practical conclusion: the platform gives you tools, the policies are yours to get right. Lovable now offers the security scans described below. Various blogs publish their own scans of Lovable apps with alarming percentages; we do not repeat their figures here, because they come from vendors selling scanners and have not been independently verified.

The two keys, and the one that must never leak

Supabase’s documentation is blunt about the secret key: it must never reach a browser, not even on a local machine, and the platform now rejects browser requests that use one. That block does not make a leaked key harmless; an attacker can use it from any other tool. The same page announces that the legacy anon and service_role keys are being deprecated by the end of 2026, which is a good moment to rotate yours.

Where does a secret key leak in practice?

• In front-end environment variables. In a Vite project, which is what Lovable generates, any variable prefixed with VITE_ is bundled into the JavaScript sent to every visitor.
• Pasted into the chat. Lovable’s security documentation says it detects API keys pasted into the conversation and steers you to its Secrets store, because secrets cannot be stored safely in client-side code.
• In the Git history. A key removed from the code is still in earlier commits. If it was ever committed, rotate it.

The six RLS mistakes to look for

These patterns come straight from the checks Supabase itself runs in its database advisors and from its Row Level Security guide.

1. A table with RLS turned off

The advisor flags this as an error (lint 0013, RLS disabled in public): a table in the exposed schema can be read and modified by anyone with the project address. Supabase’s guidance is simple: enable RLS on every table in an exposed schema, without exception, including the tables you think nobody knows about.

2. A policy that says “true”

When RLS is turned on with no policy, nothing gets through and the app breaks. The quick fix, often suggested by an assistant in a hurry, is a policy whose condition is always true. Supabase flags it (lint 0024, permissive RLS policy) because it effectively switches RLS off. A table with RLS enabled and a “true” policy looks protected in a dashboard and is not.

3. A policy that checks the role, not the owner

“Authenticated users can read invoices” sounds reasonable. It means any logged-in user can read every invoice, including those of other customers. In a SaaS, the useful question is never “is this person logged in?” but “does this row belong to this person, or to their organisation?”. Each policy should compare the row’s owner or organisation with the current user.

Supabase adds a subtle trap: when nobody is logged in, the function that returns the current user returns null, and a comparison with null silently fails. Its guide recommends checking explicitly that a user is present.

4. Reads protected, writes forgotten

A policy has two halves. The USING clause filters which existing rows an operation can see; the WITH CHECK clause decides whether a new or modified row is acceptable. A common gap is a correct read policy paired with an update policy that lets a user change a column they should not touch: their own role, the organisation a record belongs to, a price, a status. Check each operation (select, insert, update, delete) separately, and list the columns a user must never be able to change.

5. Trusting data the user can edit

Supabase flags policies that rely on user metadata (lint 0015) as an error, because users can edit that metadata themselves. A policy that grants admin rights because the user’s profile says “admin” lets anyone promote themselves. Roles belong in a table that only the server can write to.

6. Side doors: views, functions and storage

RLS protects tables. Several objects ignore it unless you take care:

• Views run with their creator’s rights by default. On Postgres 15 and later, Supabase recommends the security_invoker option so the view follows the policies of the underlying tables (lint 0010 flags the risky case).
• Functions declared as security definer run with their owner’s rights. If anonymous or logged-in users can call them, they can bypass RLS (lints 0028 and 0029).
• Storage buckets have their own policies. A public bucket with a broad listing policy lets anyone enumerate its files (lint 0025). Contracts, invoices and identity documents never belong in a public bucket.
• Materialized views and foreign tables cannot use RLS at all, so they must not be exposed through the API (lints 0016 and 0017).

The check-list, in the order we would run it

You can do the first half yourself, without writing code.

1. Run Lovable’s scans. The quick scan runs when you open the publish dialog and reviews database access rules, dependencies and exposed services; the deep scan, started from the Security view, reviews access control, unsafe input, leaked secrets, payments and authentication. Resolve every critical finding. Workspace owners can block publishing while critical issues remain.
2. Open the Supabase Security Advisor (or the database checks in Lovable Cloud) and clear every error, then read every warning.
3. List your tables and, for each one, write one sentence: who may read a row, who may create one, who may change it, who may delete it. If you cannot write the sentence, the policy cannot be right.
4. The two-customer test. Create two accounts in two different organisations. As the first, try to open the second one’s records: through the interface, then by changing an identifier in the address bar. Note that a filtered read returns zero rows rather than an error, so “nothing happened” has to be checked carefully.
5. The logged-out test. Visit the app without an account and try the pages and actions that should require one.
6. The self-promotion test. As an ordinary user, try to edit your own role, plan or organisation from the profile screen.
7. Search for secrets. Look through the front-end code and the Git history for anything that looks like a secret key, a payment provider key or an email service password. Rotate whatever you find.
8. Check storage. List every bucket, its visibility and its policies.
9. Check performance. Supabase’s guide recommends indexing the columns your policies filter on, and wrapping the current-user function in a sub-select so it runs once per query rather than once per row. A slow policy is often “fixed” later by loosening it.
10. Write it down. Keep the sentence per table and the test accounts. Every new feature generated by the AI should be re-tested against them.

Steps 3 to 6 are where business knowledge matters most. No scanner knows that a site manager should see their own team’s timesheets and not the neighbouring site’s.

What the scanners cover, and what they cannot

Lovable says it plainly: the tools cannot guarantee complete security, and a professional review is advisable for apps handling sensitive data. If your app stores health data, financial data, identity documents or data of customers’ own clients, treat that advice as a requirement.

When to bring in a developer

Some situations go beyond a check-list:

• Multi-tenant logic. As soon as users belong to organisations, with roles inside each one, policies get layered. Our explainer on multi-tenant SaaS architecture shows why isolation between customers is a design decision, not a setting.
• Server-side logic. Payments, invoicing, sending emails or calling other systems with secret keys belong in server functions, not in the browser.
• Enterprise customers. A security questionnaire from a large customer will ask about access control, logs, backups and incident response, not about which generator you used.
• Personal data at scale. GDPR requires security measures appropriate to the risk. A data leak caused by an open table is still a leak you have to notify.

None of this means the prototype was a mistake. It has already proved the need and the user journeys, which is the hardest part. Our guide to taking a Lovable app to production explains how to decide what to keep, harden or rewrite, and Lovable vs Bolt vs Base44 compares how each tool handles the back end.

The most expensive mistakes

• Treating a passing scan as a security audit. Lovable itself describes its database checks as automated checks, not a full audit.
• Fixing a broken screen by loosening a policy. Each “true” added to unblock a feature reopens a table.
• Testing with a single account. Every leak between customers is invisible to someone who only ever logs in as themselves.
• Letting the AI regenerate policies unseen. A later prompt can rewrite a policy you had fixed. Re-run the two-customer test after each significant change.
• Forgetting the old keys. A rotated key that still sits in a forgotten script or in the Git history is still a leak.

How we work on these apps

LPR Studio builds and runs software for businesses, including our own products, with the same rules on access control that we apply to client projects. If you have a Lovable prototype that real customers are about to use, we can start from it: we present a free prototype of the production version on a video call within 5 working days, with the access rules written in plain language before any code is hardened. If you are unsure what stage you are at, our note on the differences between a prototype, an MVP and a proof of concept helps you place it, and what it costs to build a SaaS platform gives the budget side.