// Security by tool
Security for apps built with Lovable
Quick answer
The classic hole in a Lovable app is not exotic: it is Row Level Security (RLS) turned off on the Supabase tables. Without RLS, the anon_key sitting in the frontend bundle lets anyone query the table directly, with no login, and pull the entire list of users, payments and keys. No special credentials, just open DevTools.
This is not theory: CVE-2025-48757 exposed 170+ Lovable apps for exactly this missing RLS, and a 50-app audit found 89% with RLS disabled on Supabase. If you shipped on Lovable and have login or billing, that is the first thing to review.
What Lovable tends to generate wrong
Lovable ships product fast on top of Supabase, but it delegates access control to you, and that is where it breaks. The architecture is client-driven: the browser talks directly to Supabase, so what protects the data is the RLS policy, not the screen code.
| Hole | Why it happens | Impact |
|---|---|---|
| RLS off on the table | Table created without a policy is public via anon_key | Whole-table dump with no login |
| anon_key treated as a secret | It is public by design, but without RLS it is a master key | Direct read/write on the database |
| Public storage bucket | Bucket without a policy exposes everyone’s uploads | File/photo/document leak |
| Plan rule only in the frontend | Paid-access check on the screen, not in the database | Regular user reaches paid resource |
How RET reviews a Lovable app
The review is not running a scanner and mailing a PDF. RET opens the flows that touch data and money and tests what the anon_key actually reaches: which tables answer without login, which buckets open, where the plan rule only exists in the frontend. Every finding ships with reproduction steps and fix priority.
For the first pass on your own, the Promptbook has the exact prompts to check RLS, buckets and keys with the AI you already use. When a serious signal shows up, Risk Review reads 1 to 3 flows and says what to fix now.
- Real test of what the anon_key reaches without authentication.
- Table-by-table map: RLS on/off and correct policy.
- Storage bucket check and plan rule in the right place (database, not screen).
You may already be exposed if
Some signals deserve an immediate review, not a mental note for later. If any of these match your app, treat it as a priority.
- You created a Supabase table through Lovable and never wrote an RLS policy.
- Your app has a paid plan, but the access check lives in the screen component.
- You have file upload and never checked whether the bucket is public.
- A B2B customer asked for security proof and you do not know what the anon_key exposes.
Frequently asked questions
Is the Supabase anon_key a secret?
No, it is public by design and lives in the frontend. The problem is that without RLS enabled and a correct policy on each table, that public key becomes direct database access. The protection is RLS, not hiding the key.
How do I know if my Lovable app has RLS off?
In practice, by testing: a query with the anon_key, no login, that returns rows from a sensitive table proves RLS is off or the policy is wrong. It is the first test RET runs, and the Promptbook guides you to do it yourself.
Is this a Lovable problem or mine?
Both. Lovable accelerates a lot, but it delegates access control to you by default. The app is yours, the data is yours, so the correct policy is the responsibility of whoever published it. The good news is that fixing RLS is fast once you know where to look.
Who runs the review at RET?
Gabriel Lima Ferreira, founder and lead pentester. The review runs with a verified domain, accepted terms and authorized scope, and returns reproducible evidence with fix priority.