Reeve Is your Lovable app safe?
Is Lovable safe to build on? Usually yes. What decides it is a database setting made the day your project was created, and you can check it today.
Logos are the property of their respective owners, shown to indicate compatibility.
In short
- A Lovable app is usually safe on the code side. What decides whether your data is safe is one per-table Supabase setting.
- Finding an API key in your app is normally fine. A publishable key belongs there; sb_secret_… or service_role does not.
- Supabase enables Row Level Security for tables made in the Table Editor, but not for tables created by running SQL, and running SQL is how a builder makes them.
Lovable gets you from an idea to a working app faster than anything else, and the part it handles for you is the part you never see: the database, the tables, the rules about who can read them. When someone tells you your Lovable app is "leaking data", that is usually where the answer is, and it is not somewhere you can look from inside the editor.
Here is the part that guide after guide gets wrong: the risk is almost never the code Lovable wrote for you. It is one database setting, decided the moment a table was created, that most write-ups either skip or describe backwards.
What Lovable actually builds, and which half is public
Two halves, and only one of them is private.
Think of it as a shop. Lovable builds you a shopfront (the pages, the buttons, the forms), and that shopfront is handed in full to every visitor. Anyone can read it. That is not a flaw; a browser cannot display a page it has not been given. Behind the shopfront is a stockroom, your Supabase database, which is a separate building with its own lock.
The mistake that costs people is assuming the shopfront controls the stockroom. It does not. Removing a button from your app is taking down a sign, not locking a door. Your database is reachable directly, over the internet, by anyone who has its address, and its address is printed on the shopfront, because that is how your own app talks to it.
Is a key in your Lovable app's code a problem?
Usually not. It depends entirely on which key it is, and there are two kinds that look nearly identical.
A publishable key says which project a request belongs to and nothing more.
Supabase names it sb_publishable_… in new projects and anon in older ones,
and it is designed to sit in your app where anyone can read it. A secret key
is the opposite: sb_secret_…, or service_role in older projects. It ignores
every rule you have set and can read and write every row in every table.
The two sit next to each other in the Supabase dashboard, look the same length, and behave identically while you are building. Copying the wrong one is a single misplaced click, and nothing breaks afterwards, which is exactly why it goes unnoticed. If you want the longer version of how to tell them apart, we wrote one.
What decides whether strangers can read your data
Row Level Security, a per-table switch in Supabase that decides row by row who is allowed to see what. With it off, your publishable key reads the whole table. With it on and a policy written, it reads only the rows that policy allows.
Now the part that matters for a Lovable app specifically. Supabase enables Row Level Security by default for tables created in the dashboard's Table Editor, the point-and-click one. Tables created by running SQL do not get it enabled, and have to be switched on deliberately.
Running SQL is how a builder creates tables for you.
So the usual shape of a Lovable project is a handful of tables you added by clicking, which are protected, sitting beside the tables that were generated for you, which may not be. Both look identical in the editor. Neither will complain. And switching the setting on is still not the finish line, because a table with Row Level Security enabled and a policy that permits everyone is open in a way that reads as closed.
How to check your own Lovable app in about ten minutes
Open Supabase, then Authentication → Policies. Read down the list of tables. Anything marked as having Row Level Security disabled is readable by anyone with your project address, which is public.
Check the key your app ships. In Supabase, go to Settings → API. If the key your app uses is the publishable one, that is correct and nothing needs doing. If a secret key has ever been pasted into your Lovable project, rotate it there first: deleting it from your code does not close the door, because the old value still exists in anyone's cached copy of your site.
Look at your storage buckets. Anything marked public can be listed and downloaded by anyone, whether or not your app links to it.
Then look from the outside. The checks above tell you what is set; they do not tell you what a stranger can actually reach. That is the gap our free scan fills. It reads your live site the way any visitor would and gives you a grade in about 20 seconds, with no account: scan your app.
What to do
- The shopfront is public by design. Everything Lovable ships to a browser can be read by anyone, and no amount of hiding changes that.
- A publishable key in your app is correct. A secret key (
sb_secret_…orservice_role) is the one to rotate today. - Tables made in Supabase's Table Editor get Row Level Security on by default. Tables created by running SQL do not, and that is how a builder makes them.
- Turning Row Level Security on is step one. A policy that allows everyone leaves the table open while the dashboard reports it as protected.
- Removing a screen or a button from your Lovable app changes nothing about what your database will answer.
The fastest useful thing you can do today is open Authentication → Policies in Supabase and read the list. If any table there says Row Level Security is disabled, start with that one, and if you would rather work through the whole surface as a list, the 10-minute security checklist covers the rest.
What can actually go wrong with a Lovable app
None of these mean you did something wrong. They come with building fast. Here are the ones worth checking:
A secret key shipped to the browser
A "secret key" is the master password to a service you use: your database, an email tool, an AI API. It's meant to live on a server. Sometimes one slips into the code that runs in your visitor's browser, where anyone can read it, and someone could use it to reach your data or run up bills in your name. There is a nuance, though. Some keys are meant to be public (Lovable and Supabase call these "publishable" or "anon" keys), and those are fine. Reeve knows the difference, so a safe key never triggers a false alarm.
Your database left open (Supabase RLS off)
Lovable apps usually store data in Supabase. Supabase has a safety switch called Row Level Security (RLS) that decides who's allowed to read or change each row. If it's off, your tables can be readable, or editable, by anyone who finds the address. This is the difference between "my data is mine" and "my customer list is public," and it's the single most common issue in vibe-coded apps.
An exposed .env or config file
The .env file is where a project keeps its passwords and keys. Now and then it gets published alongside the app by mistake. If it's reachable, it's a shortcut straight to everything sensitive. Reeve checks whether yours is quietly accessible.
Public file storage
If your app lets people upload files (photos, PDFs), those live in storage "buckets." A bucket left public means anyone can browse or download what's inside, so an upload meant for one person can end up visible to everyone. Reeve checks whether your buckets are listable; it never downloads anyone's files.
Source maps left on
A "source map" is a behind-the-scenes file that reveals your app's original code. Handy while building, but if it ships to production it hands strangers a readable copy of how your app works, which makes every door above easier to find. Not urgent alone, but worth tidying.
Missing safety headers & open endpoints
Small settings that tell browsers how to protect your visitors, plus whether your app's data endpoints answer to anyone or any website. Each one is minor on its own, but together they widen the gap. Reeve flags the ones that are missing.
What Reeve is, and what it isn't
Reeve is a free, read-only check from the outside, like a home inspector walking the perimeter and trying the doors. It catches the common, high-impact mistakes fast. It is not a full security audit, and a clean grade isn't a guarantee; it means the obvious doors are shut.
Lovable is a capable tool, and its team keeps adding security guardrails; Supabase also has a built-in advisor that flags RLS problems inside its dashboard. Both are genuinely useful. What Reeve adds: you live in Lovable, not in the Supabase console, and those tools speak developer. Reeve looks across your whole app from the outside, the way a stranger would, and tells you what it finds in words you can act on. And if you'd rather never open this tab again, Reeve can do the watching.
Want it handled, not just checked?
Reeve Care keeps watching your app, backs up your data, and helps you fix what breaks, so you can keep building instead of worrying.
Learn about Reeve CareFAQ
Is my Lovable app secure by default?
Lovable gives you a solid starting point and keeps improving its defaults, but "secure by default" still depends on how your app is set up, especially your Supabase database rules. The only way to know is to check what's actually exposed, which Reeve's free scan does in about 20 seconds.
Can a Lovable app leak my API keys?
It can happen, usually when a key that belongs on a server ends up in the front-end code. But not every key is a problem: some are designed to be public. Reeve reads your app's loaded code, finds any keys, and tells you which are safe and which need to move.
What is Supabase RLS and why does it matter for my Lovable app?
RLS (Row Level Security) is Supabase's rule for who can see or change each row of your data. If it's off, your tables can be open to anyone. Since most Lovable apps use Supabase, it's the most important thing to get right, and Reeve checks it without ever reading your actual data.
Will scanning my Lovable app break anything or change my data?
No. Reeve only looks at what's already public from the outside. It never logs in, never changes anything, and never downloads your files. Read-only, like checking whether a door is locked without stepping inside.
Lovable built my database for me. Does that mean it is set up safely?
Not automatically, and the reason is specific. Supabase turns Row Level Security on by default for tables you create by clicking around in the Table Editor. Tables created by running SQL do not get it, and running SQL is how a builder creates tables for you. So the tables you made by hand are usually protected and the ones Lovable made may not be.
Which of my tables have Row Level Security turned on?
Open your Supabase project, go to Authentication, then Policies. Every table in your public schema is listed with whether RLS is enabled. Anything showing as disabled is readable by anyone who has your project URL and your publishable key, both of which are in your app.
I found a key in my Lovable app. How do I tell whether it matters?
Read what kind it is. A publishable key (named sb_publishable_ in new Supabase projects, or anon in older ones) belongs in the browser and is not a leak. A secret key, sb_secret_ or the older service_role, ignores every rule you set and should never reach a browser. If you find that one, rotate it in the Supabase dashboard before anything else.