Lovable’s Security Scan Said Ship. Here’s What It Still Misses

On November 10, 2026, Lovable's head of security published Find it, fix it, ship it. The message to founders is that security is now part of the product: a scan on every publish, a deeper scan you can run for free, a Fix button, and an Auto-fix toggle so the agent remediates findings while you keep building. That is a real improvement on the era when a Lovable app shipped with no scan at all.

It is not a ship decision. Lovable's own security overview says the same thing in the warning at the top of the page: these tools help identify common issues, they cannot guarantee complete security, and they do not replace a thorough review — especially if the app holds sensitive data or does anything critical. The publish dialog can look green while a second account still reads the first account's rows.

This note is for founders whose Lovable app already has users, or is about to. We cover what Quick scan and Deep scan actually run, what Auto-fix will and will not touch, what still misses after "ship," and the checks that belong to you. The 2026 audit numbers sit in Lovable app security holes. The database version of the same failure is Supabase RLS mistakes. The repair decision is when to hire a developer.

What Lovable shipped in the security push

Igor's post splits the work into four buckets: what Lovable handles without you seeing it, what it flags, what it will fix, and what it still needs you to do.

Handled by default, including on free accounts: secure sign-in and access controls set up for you, secrets encrypted and kept out of frontend code, scanning as you build. That is platform posture. It is not a statement about the policies on your tables.

Flagged on publish: scanners look at code, application logic, database schemas, and row-level security policies, and they tell you before the app goes live. Want more? Run a deep scan anytime, free. Lovable says it is trained on the issues that show up most often in Lovable apps.

Fixed in product: select Fix, and the agent gets instructions for that finding. The most common issue they see is data access rules that are too open. Turn on Auto-fix security issues and many findings resolve on the next chat message. Workspace admins can block publishing while critical findings are open.

Still yours: review findings, or let auto-fix run. A finding can be intentional — usernames on a public forum. The app is yours, and so is the final call. Coming later in the month: a redesigned findings UI, and scheduled scans on paid plans. Enterprise already has scheduled Deep scans in the docs; the blog's "all paid plans" line is the expansion.

None of that is marketing we inferred. It is the announcement. The operational detail — what actually runs, when, and what Auto-fix refuses — lives in the security overview, which is the page to keep open while you decide whether to publish.

Quick scan is not Deep scan

Lovable ships two built-in scans. Mixing them up is how "the scan said ship" happens.

Quick scan finishes in seconds and runs automatically every time you publish. The publish dialog starts it in the background and shows a single line. Click through to the Security view if there are issues. Coverage, from the docs:

• Database access rules and settings: tables without per-record control (RLS), rules that let everyone through, leaked-password protection off, related storage rules
• Dependency audit: known vulnerabilities in npm packages. Only critical advisories become findings. Some critical issues are suppressed when Lovable has confirmed they cannot affect Lovable apps, or when EPSS (exploit probability) is low; those stay marked in the dependency list
• MCP server check: an MCP server the app exposes without authentication

If the workspace has connected Wiz, Quick scan also runs Wiz and shows those findings beside Lovable's.

Deep scan includes everything in Quick scan, then reads application code for logic, permissions, and data. The documented areas:

• Access control, including server code that bypasses the rules the database enforces
• Unauthenticated and abusable endpoints
• Unsafe input and injection (query, command, path, browser, email, prompt, spreadsheet)
• Leaked secrets in source or easy-to-guess tokens
• Payments and billing: prices or paid features a customer can change or reach without paying
• Authentication and account recovery
• Personal data in errors and logs

Severity labels are Critical, Warning, and Info. Findings group by security area in the Security view.

Deep scan does not run automatically as you work. You start it from the Security view, the workspace Security center, or by asking in chat. The publish dialog runs Quick scan and links to Deep scan; it does not run Deep scan for you. The documented exception: publishing an app whose MCP integration allows access without sign-in also starts a Deep scan in the background.

That split is the whole story of a green publish. Quick scan never claimed to read your routes. A payment webhook that does not verify a signature, a TanStack server function that uses an admin client and skips RLS, an IDOR in a handler that looks fine in SQL — those are Deep scan and live-app territory. If you never clicked Run deep scan, you shipped on the short checklist.

Lovable is blunt in a note on the same page: you are responsible for the security requirements of the use case. Keybrum's November 10 guide quotes Igor Andriushchenko, then CISO, telling The Register in February 2026 that applying scan recommendations is at the user's discretion. The November blog still needs you to review or auto-fix. A scanner that can be ignored is not a gate unless the workspace setting Block publishing with critical issues is on. New Enterprise workspaces start with that enabled. Other plans do not, unless an admin turns it on.

What Auto-fix actually touches

Auto-fix is easy to over-read. The docs are narrower than the blog's "many findings."

When it is enabled, Lovable adds a few of the latest Critical database findings and dependency findings from the Quick scan to the next build request, then tries to resolve them in the same response. That consumes ordinary build credits. It is designed for findings that are safe to remediate automatically: common RLS misconfigurations, database access patterns, and dependencies with known vulnerabilities.

It does not apply fixes for Deep scan findings.

Workspace admins set a default (selected projects, externally published projects, all published projects, or all projects). After a project is published under the stricter options, you often cannot turn Auto-fix off at the project level. That is a governance choice, not a proof that Deep scan issues are closed.

Fix in the Security view is a separate path: individual findings, groups, or Try to fix all. Keybrum notes a small pool of free fixes that refresh on a delay, then credits. Either way, the agent is applying a template to a finding. The most common Lovable issue — open data rules — often yields a better policy. It can also yield a policy that still never compares auth.uid() to the row owner, or a security definer function that stays callable. After Fix, open More → Database → Manage → Policies and read what landed. The scan that just went green is not a substitute for that read.

Conversational "review my app's security" uses build credits, runs Quick scan, starts Deep scan in the background, and explains findings in chat. Useful. Still static. Still not a second login.

What a green ship still misses

These are the gaps after Quick scan is clean. Several remain even after Deep scan.

The scans are static. Lovable says so when it introduces Aikido: built-in scanners and Wiz read code and configuration. They do not send requests to the running app. Optional Aikido pentests do — billed separately, recommended after you fix scanner findings. If you did not connect Aikido, nobody with another session tried your URLs. The test that closed 91% of deployed vibe-coded apps in the audit was not a linter. It was a person or a tool hitting a live route. SUSVIBES made the other half of the point: functionally correct 57% of the time, secure 11.8%. The screen can pass and the access check can still be missing.

Deep scan is optional at publish. Founders who "ran the security scan" usually mean the line in the publish dialog. That is Quick scan. Payments, injection, and server-side bypasses are on the Deep list. Skip Deep scan and you skipped the pass Lovable itself says reviews application logic.

Auto-fix will not close Deep findings. A Critical payment or auth issue in Deep scan waits for you, Fix, or a person. Leaving Auto-fix on and publishing is not the same as a Deep pass.

RLS-on is not RLS-correct. Quick scan flags tables without per-record control and rules that let everyone through. It will not necessarily catch a policy that only checks authenticated with no owner column, a view that bypasses the table, or a function written backwards. The Register's February 2026 case was a showcased app with 16 vulnerabilities, six critical, and more than 18,000 records exposed. One bug blocked signed-in users and let anonymous visitors through. Lovable said the pre-publish scan had made recommendations that were not applied, and that some code and the database were not Lovable-hosted. A check that RLS exists does not see inverted logic. A request from outside does.

CVE-2025-48757 is the volume version of the same miss. Researchers looking at 1,645 showcase apps found inadequate RLS on 170 of them — about one in ten of that sample — with NVD scoring 9.3. Lovable disputes the CVE framing because each customer protects their own app. That dispute and the scan product can both be true: the platform offers a check, the app is still yours, and a green publish in 2025 did not mean the table was closed. The November 2026 tools are better. They are still not a second account.

Server code can walk around the database. Apps created from 13 May 2026 (later for Enterprise) use TanStack Start with server rendering. Keybrum's reading of the stack: server code that uses an admin key skips RLS and must check ownership itself. Deep scan is documented to look for server code that bypasses database rules. Quick scan is not. If you only published, that bypass was not in the automatic pass.

Webhooks, prices, and the success page. Deep scan lists payments: prices or paid features a customer can change or reach without paying. Quick scan does not. Our Stripe webhook note is the live failure: unsigned handler, success URL treated as paid, retries that double-fulfill. A Lovable Fix for RLS will not invent constructEvent. Test mode still hides it.

Ignored findings stay ignored. The Security view lets you ignore a finding with a reason. Forums need public usernames; that ignore can be honest. Ignoring "table without RLS" because the UI hides the admin page is how the Data API stays open. Review the ignored list before you call the scan green.

Trust center is not a certification. Lovable can publish a page at /.well-known/trust.html with facts it observes about the live app. The docs call it informational, not a certification, and say your app's code cannot edit the results. Show it to a buyer if you want. Do not treat it as a pentest report.

What to run before the next publish

Do these in order. The first items are free inside Lovable. The last items are the product.

1. Block publishing with critical issues if you can. Workspace settings, Security. If you cannot, treat every Critical as a stop anyway.
2. Run Deep scan, not only the publish line. Wait until the Security view says the result matches the current version.
3. Read policies, not only findings. Tables, anon grants, true conditions, missing auth.uid(). The seven generated mistakes are listed in the RLS post.
4. Fix, then re-scan. Confirm the policy text. Auto-fix is for a few Quick Criticals, not a substitute for this loop.
5. Search the repo and the built frontend for sk_live_, service_role, VITE_ secrets that are not the publishable key. Rotate anything that was ever in chat on a project that was public. Lovable's April 2026 public-project episode is the reminder: code of a public project is visible by design; chats were accidentally re-opened and then reverted.
6. Two accounts. With B, request A's objects by id on every read and write. A 200 is a finding the scanner did not have to see.
7. Signed out. Private window, same URLs. Data in the first JSON response is a finding.
8. Payments. Signature on the webhook, no fulfillment from the success URL, Price ids on the server. Resend the event twice; one order.
9. Aikido or a person if the app holds personal data, money, or health. Lovable recommends scanners first, then a pentest before a major release. We will do the two-account pass on a scope call either way.

If you cannot tick 3, 6, and 8, do not add the next feature. Prompting "make it secure" after a green Quick scan is how the last open policy comes back.

When the scan is the wrong layer

Sometimes the findings are noise and the product is the problem. Open sign-up plus policies that only check "is signed in" means any stranger who creates an account is inside. A public project with keys in chat means the keys are burned even if today's scan is clean. A workspace full of apps nobody owns is a Security center problem: Business and Enterprise get a portfolio view; everyone else still has to open each project.

Lovable will keep carrying more of the load — scheduled scans, clearer findings. That is good. The 2026 audit still found access control in 64% of deployed vibe-coded apps it looked at. Tools got better in November. Attackers still try the Data API with the public key, because that is how the stack is designed. The lock is the policy and the live test, not the badge in the publish dialog.

How Techtribe takes a Lovable security repair from here

On the scope call we open the Security view, the policy list, and the live app with two accounts. We tell you which findings matter, which ignores are unsafe, and whether a green Quick scan hid a Deep issue or a live IDOR. You leave with a fixed scope and a price. The call is free.

When the core flow works, we close the dangerous paths and leave working screens. When auth was never real or the data model cannot be saved, the honest scope is a Production MVP or a Dedicated Team on your repo. The Lovable-specific take-to-production page is build/lovable. Prices are on packages.

Bring the published URL, Security view access you are willing to share, and one account that should not see the data. If it can, that is the meeting. If the hole is already public, say so in the first minute and we treat the secrets as burned.