Lovable security scan: what it misses
A green security scan feels like a clean bill of health. It is closer to a smoke alarm: useful, worth listening to, and silent about the things it was never built to detect.
As of October 10, 2026, a passing Lovable security scan means your app has none of the common problems the scan looks for. It does not mean the app is safe. The quick scan that runs before every publish checks database access rules, row-level security, password protection, known-vulnerable packages and MCP servers. Lovable's own announcement of June 1, 2026, says this basic scan does not analyze your application code for logic flaws. The on-demand deep scan does read your code, but no scan knows your business rules, such as who may see which record or what a customer must pay. Run the deep scan, fix the warnings, then have a person test the money and permission paths.
This guide is for founders who have seen the scan pass, or seen warnings they do not understand, and want to know where they stand. It covers what each scan checks, what none of them can, what the common warnings mean and what a human review adds. Platform facts come from Lovable's and Supabase's documentation and Lovable's blog, listed under Sources.
What does Lovable's security scan actually check?
Lovable has several layers. Its documentation describes them like this:
- Quick scan: runs automatically on every publish and takes about 10 seconds. It reviews your database (access rules, row-level security, password protection), audits npm dependencies for known vulnerabilities and checks MCP server authentication. Free, no credits.
- Deep scan: run by hand from More, then Security. It includes the quick checks plus access control, unauthenticated or abusable endpoints, unsafe input and injection, leaked secrets, payments and billing, authentication and exposed personal data. Free, no credits. The docs say it usually takes 3 to 13 minutes; Lovable's June post said 2 to 4. Lovable recommends it before a public launch, when handling sensitive data, or after big architectural changes.
- Scheduled deep scans: Enterprise workspaces can run deep scans weekly or monthly across selected projects, at 1 credit per project per run.
- Optional integrations: Wiz adds dependency and static code analysis, including hardcoded secrets, with your own Wiz account. Aikido runs AI penetration tests against the running app, sending real payloads and testing sign-in and permission flows, with a paid Aikido account and a test user. Its tests run for several hours.
Findings appear in the Security view, grouped by area and labeled Critical, Warning or Info. Try to fix sends a fix request to the chat; Lovable gives 10 free fixes a day across your workspaces, then fixes use credits. If critical issues exist, Lovable warns you before publishing but lets you go ahead, unless a workspace admin has turned on Block publishing with critical issues. Business and Enterprise workspaces also get a Security center that shows findings across every project.
What does the Lovable security scan miss?
Lovable is direct about the limits. Its documentation says automated scans cannot guarantee complete security, and that you are responsible for making sure your app meets the security needs of its use case. The Cloud settings describe the database checks as not a full audit. The gaps fall into a few groups:
| Risk | What the scan checks | What it doesn't | Who catches it |
|---|---|---|---|
| Tables with no access rules | Quick scan: missing row-level security | Nothing major; this is its strength | The scan, then a two-account test to confirm the fix |
| Rules that are too broad | Quick and deep scans flag common patterns | Whether the rule matches who should see what in your business | A person who knows your rules, plus tests as two users |
| Any signed-in user reading others' data | Deep scan: access control | Findings may be downgraded when code is only reachable after sign-in | A test with a fresh account |
| Price or plan tampering, skipped payment | Deep scan: payments and billing patterns | Your pricing, trial and refund rules | Human review and tests that call your functions directly |
| A user making themselves an admin | Deep scan: authorization | Your role model and who may grant roles | Human review of every role change path |
| Keys already leaked | Deep scan and Wiz: secrets in current code | Whether a key was already used, or is in git history | GitHub secret scanning, provider dashboards, a person rotating keys |
| Abuse at volume, such as AI cost | Deep scan: abusable endpoints | How much use is too much for your budget | Rate limits and spend caps someone sets and tests |
| Problems after publish | Nothing; scans look at code and settings | Errors, attacks and outages in the live app | Monitoring, logs and someone on call |
The third row deserves attention. Lovable's docs say a finding may be downgraded when the code it cites can only be reached after signing in. If anyone can sign up for your app, signing in is not a barrier. A stranger with a free account is a signed-in user. That is the most common way one customer ends up seeing another's records, covered in our guide to Lovable users seeing each other's data.
History is worth knowing too. The researcher behind CVE-2025-48757, a 2025 report of weak row-level security in Lovable-generated sites that Lovable disputes, wrote that the scanner of that time only checked whether a policy existed, not whether it was correct. Lovable has since added deep scans that read your code. The lesson still holds: a rule that exists is not a rule that is right.
What do the common Lovable security warnings mean?
Lovable's wording can differ from Supabase's. The plain-English meanings below follow Supabase's Security Advisor where it has a matching check.
| Warning | What it means | What to do |
|---|---|---|
| RLS disabled, or table publicly accessible | Supabase says anyone with your project URL can read, edit and delete every row. | Fix today: turn RLS on and add rules tied to each row's owner. |
| RLS enabled, no policy | No data can be read or written through the API. Looks like a broken feature, not a leak. | Add the narrowest rule the feature needs. Never a rule that is always true. |
| Policy allows unrestricted access | A rule whose condition is always true, which Supabase says defeats the purpose of RLS. | Replace it with an owner or team membership check. |
| Leaked password protection disabled | Users can pick passwords already published in breach lists. | Lovable Cloud: turn on Password HIBP check. Own Supabase: Pro plan and above. |
| Security definer view or function | Code that runs with raised rights and can return data RLS would block. | High priority: limit who can run it, or make it respect RLS. |
| Sensitive columns exposed | A table with data such as passwords or SSNs is reachable without access rules. | Critical: fix now and check whether anyone read it. |
| Public bucket allows listing | Anyone can list every file in a public storage bucket. | Remove the listing rule; keep user files in private buckets. |
| Function search path mutable | A database function does not fix which schema it reads, so it could be pointed at the wrong object. | Low urgency: ask Lovable to set an empty search_path on it. |
| Vulnerable dependency | A package your app uses has a known vulnerability. | Update it, then retest the app. |
Leaked password protection checks new passwords against the Have I Been Pwned list. On Lovable Cloud, turn it on under More, Cloud, Users, Auth settings, Email: Password HIBP check. Lovable's docs call it the highest-value password setting. On your own Supabase project, Supabase's docs say it is available on the Pro plan and above.
Be careful with Ignore finding. Lovable asks for a reason, and ignored findings stop counting toward the total. Lovable's June post says the scanner's security memory learns from what you dismiss and accept. Ignore a finding only when you are sure it is intended.
How should you act on your scan results?
- 01Run a deep scanOpen More, then Security, and run a Deep scan before you launch or after a big change. The quick scan alone does not read your code for logic flaws.
- 02Fix Critical findings firstUse Try to fix, then read what changed. A fix that makes an error disappear by widening access is worse than the error.
- 03Retest after every fixRerun the scan, then sign in as two test users and check neither can see the other's data.
- 04Check Supabase's own advisorOn your own Supabase project, open the Security Advisor too. Supabase describes its advisors as deterministic checks for issues such as misconfigured row-level security.
- 05Block risky publishesIf you are a workspace admin, turn on Block publishing with critical issues, so nobody ships a critical finding by accident.
Prompting is good at fixing what the scan names. It cannot judge what the scan cannot see: whether your rules match your business, or whether a flow can be abused in steps the code never anticipated.
What does a human security review add?
A person tests what should happen, not just what the code does. In a Lovable app, these are the questions a scan cannot answer for you:
- Can a user change a price or plan? Call the checkout function directly with a different amount and expect a refusal. Our Lovable Stripe integration guide explains why payment must be confirmed on the server.
- Can a user skip payment? Reach a paid feature without a paid record, or with a canceled one.
- Can a user read another customer's data through an edge function? Lovable's guide says server code using the service role bypasses row-level security and must check permissions itself.
- Can a user make themselves an admin? Supabase warns against access rules based on user metadata a user can edit. Roles belong in a table only your server writes; see Lovable authentication and user roles.
- Can someone run up your AI bill? Look for per-user limits and a provider spend cap, not just a sign-in check.
- Does a canceled or removed user lose access everywhere, including files and old links?
Tools like Aikido's penetration tests attack the running app, which is closer to a real attacker. A person who knows your business still decides which results matter. Our glossary entries on a penetration test and a code audit explain the difference. Tool-agnostic risks are in vibe coding security risks, and the full list of checks is our Lovable security checklist.
When should you stop prompting and get help?
- Your app holds health, financial or children's data, or anything a customer would be upset to see leaked.
- Money moves through the app: subscriptions, payouts, credits.
- The same finding comes back after you fixed it, or you have prompted three times without a clean retest.
- You do not understand a Critical finding well enough to know whether ignoring it is safe.
- Several customers or teams share one database and must never see each other's data.
Our vibe-coding rescue service starts where the scan stops: engineers test the business rules, money paths and permissions, fix what they find and add tests so it stays fixed. For a quick sense of your risks, take the free production-readiness check.
On a Plutonapps plan, every change you prompt gets code review and security checks before it ships, with an engineer reading what the scan cannot. Plans are on our pricing page.
Sources
All checked on October 10, 2026.
- Lovable blog: How Lovable protects your apps automatically, June 1, 2026, on the basic scan, deep scans, scheduled scans and security memory (lovable.dev/blog/how-lovable-protects-your-apps-automatically).
- Lovable documentation: Security overview, on what the quick and deep scans check, Wiz, Aikido, the HIBP check and responsibility (docs.lovable.dev/features/security).
- Lovable documentation: Project security view, on severities, deep scan timing, free fixes, ignoring findings and blocking publishes (docs.lovable.dev/features/security-view).
- Lovable documentation: Security center, on plans, roles and scheduled scan credits (docs.lovable.dev/features/security-center).
- Lovable documentation: Wiz and Aikido integrations, on what each tests and what accounts they need (docs.lovable.dev/integrations/wiz; docs.lovable.dev/integrations/aikido).
- Lovable documentation: Publish your Lovable project, on the quick scan before publishing (docs.lovable.dev/features/publish).
- Lovable documentation: Lovable Cloud, on the security checks being not a full audit (docs.lovable.dev/features/cloud).
- Lovable documentation: Email authentication for your app, on the Password HIBP check (docs.lovable.dev/features/email-auth).
- Lovable documentation: Security best practices, on server code that uses the service role (docs.lovable.dev/tips-tricks/security-best-practices).
- Supabase documentation: Database advisors, on what each lint means and how to resolve it (supabase.com/docs/guides/database/database-advisors).
- Supabase documentation: Password security, on leaked password protection and its plans (supabase.com/docs/guides/auth/password-security).
- US National Vulnerability Database: CVE-2025-48757, on the 2025 report and Lovable's dispute (nvd.nist.gov/vuln/detail/CVE-2025-48757).
- Matt Palmer: Statement on CVE-2025-48757, on the 2025 scanner checking only that a policy existed (mattpalmer.io/posts/statement-on-CVE-2025-48757).
Common questions
Is my Lovable app secure if the security scan passes?
Not necessarily. A pass means none of the common problems the scan looks for were found. Lovable's documentation says its scans cannot guarantee complete security, and its basic scan does not analyze your code for logic flaws. Run a deep scan and test permissions and payments yourself or with an engineer.
What is the difference between Lovable's quick scan and deep scan?
The quick scan runs on every publish in about 10 seconds and checks database rules, dependencies and MCP servers. The deep scan runs on demand, reads your code and adds checks for access control, injection, leaked secrets, payments and exposed personal data. Both are free and use no credits.
How do I fix leaked password protection disabled in Lovable?
On Lovable Cloud, go to More, Cloud, Users, Auth settings, Email and turn on Password HIBP check. It rejects passwords found in the Have I Been Pwned breach list. On your own Supabase project, the setting is in Auth settings and needs the Pro plan or above.
Can I publish a Lovable app with security warnings?
Yes. Lovable warns you before publishing if critical issues exist but lets you continue. A workspace admin can turn on Block publishing with critical issues to stop that. Only critical findings can block a publish, and only with that setting on.
What does RLS disabled mean in a Lovable security scan?
A database table has no row-level security, so it has no rules about who may read or change its rows. Supabase says anyone with your project URL can then read, edit and delete all of its data. Turn RLS on and add rules tied to each row's owner, then test with two accounts.
More on this: Production architecture & security · Lovable app security checklist: is your app secure?
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.
