Lovable security audit tool: how to audit your Lovable app for free
Short answer: run Lovable's own Quick and Deep scans in the Security view, then run a free SniffPup scan (SniffPup is a free passive security scanner for vibe-coded apps) on your published URL. Fix every Critical finding, and do the two things the scans can't: test your data as a stranger and as a second user. Only audit apps you own.
Home › Guides › Lovable security audit · Last updated · By Ember, SniffPup
Where SniffPup fits: Lovable's scans read your project from the inside. A free SniffPup scan reads your live site from the outside, passively, the way a stranger would: secret keys in your HTML and JavaScript (masked in the report), public /.env and /.git files, a public source map, security headers, cookies and HTTPS, plus a read-only check of whether your public Supabase key can read rows in up to 8 tables. No signup.
A 100 means no issues were found in our checks. It is never proof of security.
1. Run the Quick scan and the Deep scan
Open your project's Security view. Per Lovable's security docs, it has two built-in scans, and running either one is free:
- Quick scan (seconds; also runs automatically when you open the publish dialog): your database access rules and settings, such as tables without row-level security, rules that let everyone through and leaked-password protection turned off; known vulnerabilities in your npm dependencies (only critical ones become findings); and an MCP server your app exposes without sign-in.
- Deep scan (you start it): everything in the Quick scan plus a review of all your app's code for access control, endpoints anyone can trigger, unsafe input and injection, leaked secrets, payments and billing, sign-in and account recovery, and personal data in error messages and logs.
The Deep scan doesn't run on its own as you build, so start it yourself before you publish and after big changes. If your workspace has the optional Wiz or Aikido connectors, their findings show up in the same view.
2. Fix Critical findings first, then read the warnings
Findings are grouped by security area and labeled Critical, Warning or Info. Fix Critical ones before you publish. You can fix one finding, a group, or use Try to fix all, then re-run the scan. If a finding really doesn't apply (say, a table that is meant to be public), ignore it with a written reason rather than leaving it unexplained. Read each fix before you accept it: an automatic change to an access rule can break a feature or open something else.
3. Check your access rules yourself
Scans flag common mistakes. They don't know your app's rules, like "a user can only see their own orders". You can review every policy under More → Database → Manage → Policies. Then test two ways:
- Signed out: with your project URL and public key, ask for one row of a table that should be private (the request is in the Supabase RLS checker guide). A row back means any visitor can read it.
- Two users: sign up two test accounts and, as user B, try to load user A's data. If it works, a rule checks that someone is signed in but not that the row is theirs. The RLS policy examples show the owner-only pattern.
If your app uses its own Supabase project, also run Supabase's Security Advisor; the Supabase security audit guide walks through it.
4. Check your keys and sign-in settings
- Secret keys go in Secrets, never in the frontend. Lovable builds code that runs in the browser, so anything in it is public. Lovable detects keys pasted into the chat and steers them into Secrets, called from server-side functions. Search your code for keys that slipped through anyway, including in
VITE_variables. - The public Supabase key is fine to ship; the secret or
service_rolekey is not, because it skips every policy. See is the Supabase anon key safe? - Leaked-password protection: if users sign in with email and password, turn on the password check against known leaked passwords (on Lovable's built-in backend: More → Users → Settings → Email).
5. Scan what your published app shows a stranger
Everything above happens inside Lovable. Visitors see something else: the HTML, JavaScript and files your published URL actually serves, and the headers on every response. Run a free SniffPup scan on your lovable.app address or custom domain. It searches your HTML and same-origin JavaScript for secret keys, tests for public /.env and /.git files and source maps, checks headers, cookies and HTTPS, and does the read-only Supabase table check. If a secret key did leak, follow what to do after leaking an API key: rotate it first. For a step-by-step look at keys, see how to find exposed API keys on your website.
Want to show customers what your live app looks like from the outside? Lovable can publish a Trust center page for externally published apps. Lovable calls it informational, not a certification.
6. Repeat after every change
The Quick scan re-runs when you publish. Run a Deep scan again after you add tables, backend functions, sign-in or payments, and re-scan the live URL after each publish. For the full pre-launch list, see is my Lovable app secure? and the vibe-coded app security checklist.
FAQ
What is the best Lovable security audit tool?
Start with the one Lovable ships: the Security view in your project. It runs a Quick scan (database access rules, critical npm dependency vulnerabilities and an MCP server check) and a Deep scan that reviews your whole app's code for access control, open endpoints, injection, leaked secrets, payments and sign-in problems. Lovable's docs say running either scan is free. Neither looks at your published website from the outside, so pair them with an outside scan of your live URL, such as a free SniffPup scan.
Does Lovable's security scan run automatically?
The Quick scan does: Lovable runs it every time you open the publish dialog. The Deep scan doesn't run on its own; you start it from the project Security view or the workspace Security center. (Enterprise workspaces can schedule Deep scans, and an app whose MCP integration allows access without sign-in also gets a Deep scan in the background when published.)
If Lovable's Security view shows no issues, is my app secure?
Not necessarily. Lovable's own docs say these tools help find common issues but can't guarantee complete security. A scan can't know who should see which rows in your app, so test your data as a signed-out visitor and as two different users, and check what your live site actually serves.
Can SniffPup audit my Lovable app?
From the outside, yes. A free SniffPup scan of your published URL (a lovable.app address or your own domain) checks what any visitor can load: secret keys in your HTML and JavaScript, public .env and .git files, source maps, security headers, cookies and HTTPS. With only the public Supabase key your site already ships, it also checks whether an anonymous visitor can read rows in up to 8 tables (read-only, no rows downloaded). It can't see your code or your policies, so run Lovable's scans too.
How often should I audit a Lovable app?
Before every publish and after any change that adds a table, a backend function, sign-in or payments. The Quick scan already runs when you publish; run a Deep scan yourself after bigger changes, then re-scan the live URL.
Does a clean SniffPup report mean my Lovable app is secure?
No. A score of 100 means no issues were found in our checks. It is never proof of security, and it says nothing about your server code, your database policies or what signed-in users can reach.
Sources: Lovable's security overview, Secrets and Trust center docs, checked October 28, 2026. Lovable changes quickly, so check their docs for the latest menus.
A score of 100 means no issues were found in our checks. It is not proof that your app is secure.