Why Lovable apps need a check
Lovable builds a real app from a conversation: the screens, the logic and, usually, a Supabase database behind it. That is what makes it so quick. It also means that a lot of decisions about security were made for you, in code you may never have read.
Most of the time those decisions are fine. The problems we see are rarely clever attacks. They are things left open by accident: a key that should have stayed on a server, a table anyone can read, a setting from development that was never switched off. Each one is usually quick to fix once you know it is there.
Your Lovable app runs in your visitors' browsers, so everything it needs to run (the page, its JavaScript and any keys inside it) is sent to anyone who opens it. Start from that idea and most of this guide follows.
Keys in your code
Your app needs keys to talk to other services. Some are made to be public, such as your Supabase project's anon or publishable key, or a Stripe publishable key that starts with pk_. Others must never reach the browser: a Stripe secret key (sk_live_), a Supabase service role key, or a key for OpenAI or another AI provider.
A secret key usually ends up in the front end when it was pasted into a prompt or into a setting that the build bundles into the page. Anyone who opens the page source can copy it and use it as you.
What to do: keep secret keys in server-side code, such as a Supabase Edge Function, and call that function from your app instead. If a secret key has ever been in your front end, treat it as leaked: create a new one, move it server side, then revoke the old one. Our guide to API keys in your front end goes through the common ones, and a free survey looks for them on your public pages.
Who can read your database
If your Lovable app uses Supabase, your app talks to the database directly from the browser with its public key. That is how Supabase is designed, and it is safe only while row level security decides who may read and change each row.
A table without row level security, or with a rule that lets everyone in, can be read by anyone who has your public key, which is everyone who has opened your app. This is the most serious problem we find in apps built this way, because it can expose your customers' details.
What to do: in your Supabase dashboard, check that row level security is turned on for every table your app uses, and that each rule only lets people see their own rows, or rows meant to be public. Then test it as someone who is not signed in. Once you have proved you own the site, a verified scan checks which tables answer an anonymous request without reading a single row.
Security headers
Security headers are short instructions your site sends with every page, telling the browser to switch on protections: only connect over HTTPS, refuse to be shown inside another site's frame, and limit which scripts may run. They do not fix bugs, but they make many kinds of attack much harder.
Where you set them depends on where your app is hosted. If your host lets you add response headers, add them there; if it does not, a proxy such as Cloudflare in front of your site can add them. A survey reports which headers are missing and, where we can tell, where to set them for your platform. Our Lovable page has more.
Things left over from building
Building an app leaves traces. The most common is a source map: a file that turns your compressed JavaScript back into readable source code. It is useful while you build, but published on a live site it lets anyone read how your app works, including any comments, test values and the addresses of your API.
Others are development settings that were never switched off, or addresses that point at localhost. None of these is a break-in on its own, but each makes the next problem easier to find. A survey checks for published source maps and development leftovers.
What no scan can see
A scan from the outside sees what any visitor can see. It cannot judge whether one signed-in customer can open another customer's order, whether your password reset flow can be abused, or whether your business logic can be tricked. Those questions need someone to read the code and try the app as different users.
So a clean survey is a good sign, not a guarantee. If your app handles payments, personal data or anything your customers would be upset to lose, it is worth having a person look properly before launch. That is what our security audit is for.