Lovable security audit: what the built-in scans leave to you
A Lovable security audit asks whether a stranger holding your public key can read, change or run up the bill on anything you own. Lovable's built-in scans answer part of that question, and its documentation says they do not replace a thorough review.
Lovable security
- Quick scan
- Runs on every publish
- Deep scan
- Started on demand
- Lovable says
- Scans do not replace review
- Docs read
- 19 October 2026
- Human review
- Paid, scoped on a call
The short answer
A Lovable security audit checks which database tables a signed-out visitor can read or write, whether any private key reaches the browser, whether server functions verify the caller, and whether sign-up and paid calls have limits. Lovable's Quick and Deep scans cover part of this. For an app that holds customer data, its documentation recommends a professional review on top.
What Lovable's own scans check
Lovable ships two scans. The Quick scan finishes in seconds and runs every time you publish. It looks at your database access rules, including tables with no per-record access control, rules that let everyone through and leaked-password protection switched off. It also checks npm dependencies for known vulnerabilities and flags any MCP server the app exposes without sign-in.
The Deep scan reads all of the application code. It covers access control, endpoints anyone can trigger, unsafe input that reaches a query or an AI prompt, leaked secrets, payment logic a customer could bypass, sign-in and recovery flows, and error messages that expose personal data. It does not run on its own as you work. You start it from the Security view.
Workspaces can also connect Wiz, which adds static analysis of dependencies and source code, and Aikido, which runs AI-driven penetration tests against the running app. Lovable recommends running the scanners first, fixing what they find, and validating with a pentest before a major release.
Four ways to audit a Lovable app
Each method sees a different slice of the same app. Use the first two for every publish, and add the others as the stakes rise.
| Method | What it reads | Good at | Leaves open |
|---|---|---|---|
| Quick scan | Database rules, npm dependencies, MCP server exposure | Obvious gaps, in seconds, on every publish | Application code. Lovable lists code patterns as areas the Quick scan does not cover. |
| Deep scan | All application code | Logic, permissions, payments, secrets in source | Anything only visible when the app runs. Lovable says no scan can guarantee complete security. |
| Connected tools | Source and dependencies (Wiz), the running app under attack (Aikido) | Vulnerable packages, flows an attacker can actually exploit | Whether your rules match who should see what. A tool cannot know your intent. |
| Human production review | Repository, database policies, hosting settings and a load test | Policies against intent, grants, and what breaks under load | It costs money and a person's calendar. |
What the CVE record says
CVE-2025-48757 is the entry people cite when they say Lovable is insecure. The National Vulnerability Database published it on 30 May 2025. It describes an insufficient database row-level security policy in Lovable through 15 April 2025 that lets remote unauthenticated attackers read or write arbitrary database tables of generated sites.
The same record notes that the supplier disputes it, because each customer of the platform accepts responsibility for protecting their own application's data. Both statements can hold at once. A platform can ship safer defaults and an app can still be open, because policies are written per app. An audit reads your policies instead of reading the news.
Seven checks a human audit adds
- Policies read against intent. A policy can pass a scan and still let user A open user B's records, so test with two real accounts.
- Grants. Supabase says a policy does not remove a grant, so a table can look protected and still hand the anon role an insert path.
- Views and functions. Views bypass row-level security by default, and every function that runs with its owner's rights needs a review.
- Service role code. Server code using the service role bypasses row-level security, so each such function must check permissions itself.
- Storage buckets. Try the links as a signed-out visitor, because Lovable's backups cover the database and leave storage files out.
- Sign-in settings. Confirm email verification is on, the live domain is in the redirect URLs and leaked-password protection is enabled.
- Paid calls. Anything that calls a model or sends email needs a limit, because unbounded consumption is how a stranger runs up your bill.
What this looked like on our own product
We ran this audit on our own product in July 2026.
The Supabase advisor flagged 12 public tables in Parci with row-level security switched off. The grants showed that the anon and authenticated roles held no access to them, so a signed-out request was refused before any policy ran. Row-level security went on for the 11 tables Parci owns, and the twelfth is a PostGIS system table the advisor will always flag.
A scanner reported the same finding for all twelve tables. Reading the grants separated a warning from a leak, and that is the part of an audit a scan cannot do for you.
An audit you can run yourself today
- Run both scans. Open the project Security view, start the Quick and Deep scans, and fix the Critical findings first.
- Read every policy. List each table and write down who should see each row before you look at what the policy allows.
- Test as a stranger. Sign out and request each table, then sign in as a second user and ask for the first user's rows.
- Look for private keys in the browser. Search the live site's loaded scripts, and treat any secret key you find as compromised.
- Call every function directly. Send each one a request with no sign-in and one with the wrong user.
- Write the findings down with a severity, an owner and a date, and run the scans again after every major prompt.
When a paid review earns its place
A self-run audit finds the gaps a scan can name. A human review finds the ones that depend on what your app is supposed to do, which is why Lovable itself suggests an additional professional review for apps that hold sensitive data or critical functions.
Digiton's version starts with a free 25-minute scoping call. If it fits, the first paid step is a production review of the real repository and infrastructure. Read access to the repository and the hosting dashboards is enough, and a staging copy is best for the load test. You get a scorecard across ten layers with evidence, the result of one load test and a fix list with a cost on every line. Security is two of those ten layers. The rest decide whether the app survives its first busy day.
The full standard is on our production engineering page. Bigger rebuilds belong under custom AI development, and agents that act inside your systems under AI agent development. For the wider launch checklist see Lovable app to production, and if you want a person to do the work, read how to hire a Lovable developer. If coding agents work in your repository, our agentjacking defense page covers how those agents get hijacked.
Sources, checked 2026-10-19
14 sources
- Lovable ships a Quick scan that runs on every publish and a Deep scan that reviews all application code, and says they do not replace a thorough security review.Source: docs.lovable.dev, checked 2026-10-19.
- The Quick scan covers database access rules, leaked-password protection, npm dependencies and MCP server exposure. Application code patterns are areas it does not cover.Source: docs.lovable.dev, checked 2026-10-19.
- The Deep scan covers access control, abusable endpoints, unsafe input, leaked secrets, payments, authentication and exposed personal data, and is started from the Security view.Source: docs.lovable.dev, checked 2026-10-19.
- Workspaces can connect Wiz for static analysis and Aikido for AI penetration testing, and Lovable recommends scanners first and a pentest before a major release.Source: docs.lovable.dev, checked 2026-10-19.
- Lovable says you are responsible for the app's security and recommends a professional review for apps handling sensitive data or critical functionality.Source: docs.lovable.dev, checked 2026-10-19.
- Lovable describes its infrastructure as SOC 2 Type 2 and ISO 27001 certified.Source: docs.lovable.dev, checked 2026-10-19.
- Server code that uses the service role bypasses row-level security and must check permissions itself. Lovable sets up basic policies automatically and says to review them early, before real data exists.Source: docs.lovable.dev, checked 2026-10-19.
- Lovable says missing row-level security policies are the most common way app data gets exposed.Source: docs.lovable.dev, checked 2026-10-19.
- Database backups cover the database only, and files in storage buckets are not part of them.Source: docs.lovable.dev, checked 2026-10-19.
- Auto-confirm email suits testing, a live app should keep confirmation on, and a missing live domain in the redirect URLs breaks sign-in.Source: docs.lovable.dev, checked 2026-10-19.
- A table without row-level security is readable and writable by any role with a grant, a policy does not remove a grant, and views bypass row-level security by default.Source: supabase.com, checked 2026-10-19.
- The Security Advisor flags tables in the public schema with row-level security disabled, and says some findings may be intentional.Source: supabase.com, checked 2026-10-19.
- CVE-2025-48757, published 30 May 2025, describes an insufficient row-level security policy in Lovable through 15 April 2025 and notes that the supplier disputes it.Source: nvd.nist.gov, checked 2026-10-19.
- Unbounded consumption of a model API can lead to denial of service and economic loss.Source: genai.owasp.org, checked 2026-10-19.
Digiton Dynamics OÜ is registered in Tallinn, Estonia, and delivers from Lisbon.
Frequently asked questions
Is Lovable secure?
Lovable describes its infrastructure as SOC 2 Type 2 and ISO 27001 certified. Your app is a separate question. Lovable says you are responsible for the security requirements of what you build, so a secure platform and a secure app are two different findings.
Does Lovable's security scan replace an audit?
No, and Lovable says so itself. The Quick scan runs on every publish and the Deep scan reads the application code, but the documentation states that they do not replace a thorough security review and suggests a professional review for sensitive data.
What does CVE-2025-48757 mean for my app?
The record describes a row-level security weakness in Lovable-generated sites through 15 April 2025 and notes that the supplier disputes it. For your app the useful reading is practical: open your policies and your grants and check them today, whatever the argument about responsibility.
How do I check my Supabase row-level security?
Run the Quick scan or the Supabase Security Advisor and read the database findings. Then test as a stranger. Request each table signed out, and request one user's rows while signed in as another. The advisor tells you where to look and the grants tell you whether the public key can reach the data.
Should I audit before launch or after?
Before the first real users and again before you take payments. Lovable's own security guide says policies are much easier to change before real data exists, and a post-launch fix has to work around live records.
Does an audit need access to my live database?
Read access to the repository and the hosting dashboards is enough for the review. A staging copy is best for the load test. Write access only comes with a later build, on terms you set.
Talk to an engineer about your system
Book a free 25-minute scoping call. We tell you what we would build, what it takes to keep it running, and whether we are the right fit.