Is Lovable safe? What its security scans cover, and what is still yours
Lovable is a reasonable place to build. It runs a free Quick scan on every publish and offers a free Deep scan that reads your app's code for access control, payment and injection problems. Run the Deep scan before launch. What no scanner can decide for you is what each user is supposed to see, so test that yourself with a second account.
You built an app with Lovable. It loads, people can sign up, data saves. Now somebody has asked whether it is secure, and the honest answer has two halves: what Lovable checks for you, and what only you can check.
The first half has grown. An earlier version of this page described Lovable's own check as a configuration review at publish time. That is out of date: Lovable now also reads your application code, and both of its scans are free. That changes what you should do first.
What does Lovable check for you?
According to Lovable's security documentation, there are two built-in scans. The Quick scan runs automatically every time you publish. It reviews your database access rules (tables with no row-level security, rules that let everyone through, leaked-password protection turned off), audits your npm dependencies for known vulnerabilities, and flags an MCP server your app exposes without authentication. Only dependency vulnerabilities rated critical become findings.
The Deep scan reviews all of your application code. It includes the Quick checks and reports on access control (users who can view or change data that is not theirs), endpoints anyone can trigger, unsafe input reaching a query, command, file path or AI prompt, leaked secrets in your code or repository, payment and paid-feature bypasses, weak sign-in and recovery flows, and error messages that leak details. You start it from the project's Security view.
Both scans are free and use no credits, per the Security view docs. Fixing a finding draws on ten free fixes that each come back 24 hours after use; beyond those, fixes use credits. Whether open findings block publishing depends on your workspace settings. Lovable also hosts the app, handles HTTPS and patches the servers under it, and it steers API keys pasted into chat into its Secrets store instead of your frontend code.
When is Lovable's own scan enough?
For a small app with one kind of user and no payments, a clean Deep scan plus the two-account test below is a reasonable bar before launch. Run the Deep scan again after any change to sign-in, payments or database tables, because that is when access rules drift.
Expect to want more than that when real money or other people's personal data is involved, when the app has several roles such as admin, staff and customer, or when parts of it live outside Lovable. Those are the cases where a second, independent read of the code is worth its cost, and where a person who understands what each role should see is worth more than any scanner.
What is still mine to check?
The part no scanner can infer is what your app is supposed to allow. These checks are about intent as much as code, and each takes a few minutes.
Who can see whose data. Log in as user B and open a URL or call an endpoint that belongs to user A, for example by changing /orders/1041 to /orders/1042. A scanner can spot a missing ownership check in code it recognises. It cannot know that a manager should see their team's records but not another team's, and the flaw stays invisible while you only ever test as yourself.
Keys in the browser. On the deployed app, open developer tools and search every loaded file for sk-, secret and token. Lovable's Supabase publishable key is meant to be there; a secret key never is. Which keys may ship to a browser explains the difference.
Your database rules, tested as users. The Quick scan flags tables with no row-level security. A rule that exists but is too generous is subtler. How to test Supabase grants and policies has a check you can run as a signed-out visitor and two users.
Your paywall. As a free user, call a premium feature directly from the network tab. If it answers, the paywall is a hidden button.
Input handling. Type <script>alert(1)</script> into a comment or profile field and see whether it runs for the next reader.
None of these produce an error. The app does not crash and nothing turns red, which is why they survive to production.
Why do AI builders leave these holes?
Because the request never mentioned them. "Let users save their favourites" is a complete instruction to a language model and an incomplete one to a security engineer. The model writes a working feature, and whether user A can read user B's favourites is a question the prompt never raised.
The same goes for "fix this error". That is how a permission gets widened from this user to anyone and then stays that way, because the error went away and nothing suggested the fix had cost anything.
Where does an outside scan fit?
Lovable's two-way GitHub sync is available on every plan, so your code can sit in a repository that other tools can read. Sentrint is one of them: it scans that repository independently, returns each finding in plain English, and writes a fix prompt you can paste back into Lovable. It is a code scan, not a pentest, and it does not log in to your running app.
Treat it as a second opinion, not a replacement. Run Lovable's Deep scan first because it is free and knows the platform, do the two-account test because no scanner can, and use an outside scan when you want an independent read. You can read a full sample report to see what one looks like, and the first scan is free with no card.