The short version
On 10 November 2026 Lovable announced that its scanners check your code, database schema and row-level security (RLS) policies when you publish, with a free deep scan and a one-click or automatic fix. That covers the most common way Lovable apps leak data: database access rules that are too open. If you build on Lovable, run both scans and fix what they find before you do anything else.
The scans read your project’s code and database configuration. They are not designed to check how the app behaves once it is deployed somewhere else, or the production settings that live outside your code: the host’s routing rules, the environment variables on another host, where your Stripe webhook points, or whether anyone will notice when the app goes down. Lovable’s own docs say the scans “do not replace a thorough security review” and that passing the publish block “does not prove that your app is secure”.
What Lovable’s scans do, per the docs
Lovable has two built-in scans. Both are free and don’t use credits.
- Quick scan. A fixed set of checks that takes seconds and runs automatically when you open the publish dialog. It reviews your database access rules (for example tables without RLS, policies that let everyone through, and leaked-password protection turned off), audits your npm dependencies for known vulnerabilities, and flags an MCP server your app exposes without authentication. Database checks only run for projects with a connected database.
- Deep scan. Reviews all your application code and includes the Quick scan. Its areas are access control, unauthenticated or abusable endpoints, unsafe input and injection, leaked secrets in source code or the repository, payments and billing logic, authentication bypasses, and personal data exposed in errors or logs. It does not run automatically: you start it from the Security view, the workspace Security center or the project chat. Lovable’s security page says it takes about 3 minutes. The one exception is an app whose MCP integration allows access without sign-in, where publishing also starts a Deep scan.
- Fixing. Each finding has a Fix button. Fixes from the Security view use 10 free fixes per account, and each one becomes available again 24 hours after you use it. After that, fixes use credits. Auto-fix security issues is off by default per project. When it is on, Lovable adds a few of the latest critical database and dependency findings from the Quick scan to your next build request and tries to resolve them. That uses credits, and it does not apply to Deep scan findings.
- Publish controls. “Block publishing with critical issues” is off by default, except in new Enterprise workspaces that Lovable creates. If it is off, you can publish with critical findings, and the dialog shows them.
- Optional add-ons. Workspaces can connect Wiz (dependency and static code scanning) or run AI penetration tests with Aikido, which are billed by Aikido, not in Lovable credits.
The blog post and the docs describe the publish-time scan slightly differently. The blog says the scanners check “your code, application logic, database schemas, and row-level security policies” every time you publish. The docs say the automatic publish-time scan is the Quick scan (database rules, dependencies, MCP exposure), and that the full code review is the Deep scan you start yourself. This guide follows the docs. To be safe, run the Deep scan before every publish that changes data access.
Side by side
“Yes” means the area is part of that option’s documented or stated scope, not that every issue in it will be found. “Not documented” means we could not find it in Lovable’s docs as of 13 November 2026, which is not the same as “never”. The free checker is ShipVibed’s production readiness checker. A manual production review means a person going through the app, its config and the code you share. A pentest means a security firm, or an AI pentest service, actively attacking a running app within an agreed scope.
| Area | ShipVibed free checker | Lovable Quick scan | Lovable Deep scan | Manual production review | Pentest |
|---|---|---|---|---|---|
| RLS and database access rules | No. It sees that your app uses Supabase and reminds you to test RLS. It never queries your database | Yes: tables without RLS, always-true policies (connected database only) | Yes, plus server code that bypasses the rules | Yes: what the public anon key can actually read and write | Yes, if the database API is in scope |
| Secret keys in shipped code | Yes: the HTML and JavaScript browsers download, masked | Not documented | Yes: secrets in source code and the repository | Yes | Usually |
| Vulnerable npm dependencies | No | Yes | Yes (includes Quick scan) | Partly: a quick audit, not a full SCA | Sometimes |
| 404 on refresh (SPA routing) | Yes: requests a deep link on the live URL | Not documented | Not documented | Yes | No: not a security issue |
| Production env vars | Partly: localhost leftovers and secrets in the bundle, not missing values | Not documented | Partly: hard-coded secrets, not values set on another host | Yes, from the repo or your description | No |
| Auth redirect URLs | Partly: localhost addresses in shipped code | No (leaked-password protection only) | Partly: sign-in and recovery flows that can be bypassed; redirect URL settings not documented | Yes: tests the flows and lists dashboard settings to check | Partly |
| Payment webhooks | No | No | Partly: prices or paid features reachable without paying, and unauthenticated endpoints. Webhook signature checks are not named | Yes, where the payment code is shared | Partly, if in scope |
| CORS | No | Not documented | Not documented, beyond abusable endpoints | Yes | Usually |
| Security headers (HSTS, CSP) | No: HTTPS and the http→https redirect only | Not documented | Not documented | Yes, as prioritised notes | Yes |
| Uptime and error monitoring | No | No | No | Yes, as a recommendation | No |
| Free-tier limits (pausing, quotas, non-commercial plans) | No | No | No | Yes | No |
| Business-logic bugs and multi-step attacks | No | No | Partly: payments and access-control logic in code | Partly | Yes: this is what a pentest is for |
Two notes on the table. A static scan reads code and config and flags patterns that look risky; a pentest sends real requests to a running app and confirms what is exploitable. Lovable’s docs say the same and recommend scanning first, fixing, then validating with a pentest before a major release. And none of these options is a certification. A clean result means “nothing found in this scope”, not “secure”.
Where the gaps usually show up
Deploying outside Lovable. If you export the code to GitHub and deploy it on Vercel, Netlify or Cloudflare Pages, the host’s settings are yours: the SPA rewrite that stops 404s on refresh, and the environment variables that must be set on the new host and redeployed.
Settings that live in dashboards. The Supabase Auth Site URL and Redirect URLs, OAuth callback URLs and the Stripe webhook endpoint are set in each provider’s dashboard, not in your code. See auth redirects to localhost and Stripe webhook signature errors.
An API on another origin. If your frontend calls an API on a different domain, CORS has to allow your production origin. See blocked by CORS policy.
After launch. No scan tells you the app went down or that your database project was paused on a free plan. An uptime monitor and an error tracker do; the monitoring tools list free options, and the database tools note each free tier’s pausing and backup limits.
Data access, tested for real. Even with a clean scan, sign in as a second user and try to read the first user’s rows. Lovable’s settings docs give the same advice: “Test your app’s access rules before publishing.” The RLS guide shows how policies should look.
A practical order
- Run the Quick and Deep scans in Lovable and fix the critical findings.
- Run the free checker on the live URL. It takes about 20 seconds and needs no sign-up.
- Work through the launch checklist for the areas no scanner sees.
- If the app handles payments or personal data, get a person to review it, and consider a pentest before a major release.
