Guide Lovable

Lovable security checklist: 8 checks before you publish

By the PatchAndShip team Last verified:

Short answer

Before you publish a Lovable app:

  1. Run a Deep scan yourself (the publish dialog only runs the Quick scan automatically) and fix every Critical finding.
  2. Read your RLS policies under More → Cloud → Database → RLS policies, and test with two accounts.
  3. Keep private keys in Secrets, not .env.
  4. Check that no storage bucket holding private files is public.
  5. Turn on leaked-password protection.
  6. Set who can open the project and the live site.
  7. Test the live app while logged out.
  8. Re-run the Deep scan after every significant change.

Lovable says its scans "do not replace a thorough security review."

1. Run a Deep scan, not just the Quick scan

The publish dialog runs the Quick scan automatically. It checks your database access rules, dependencies and MCP server exposure. The Deep scan "does not run automatically as you work." It reviews your application code for problems like users reaching data that isn't theirs, endpoints anyone can trigger, and leaked secrets. (Lovable: Security overview)

Do: open the project's Security view (More → Security), click Run deep scan (if results are current, the card shows Up to date instead of the button), and work through every Critical finding. Lovable labels Critical as "Problems that need your attention immediately." (Lovable: Project security view) Only ignore a finding if it truly doesn't apply, and note why.

2. Read your RLS policies yourself

Lovable "sets up basic RLS policies automatically, but you should review and adjust them early in development." You can see every policy under More → Cloud → Database → RLS policies. (Lovable: Security best practices)

Lovable's own pre-publish list for RLS:

  • RLS is enabled on all sensitive tables
  • Users cannot access other users' private data
  • Shared and public data behaves as intended
  • New tables are not missing policies

Do: look for policies that let everyone through, like using (true) on private data. Then run the two-account test: sign in as user A and try to open, edit and delete a record that belongs to user B. Every attempt should fail. The full SQL fixes are in How to fix Supabase RLS in a Lovable app.

Using your own Supabase project instead of Lovable Cloud? Check the same things in the Supabase dashboard.

3. Put private keys in Secrets, and only public values in .env

Lovable keeps these strictly apart:

  • Secrets (More → Cloud → Secrets) are "encrypted, injected into your Edge Functions automatically, and never reach the browser."
  • Anything prefixed VITE_ "is a build-time, browser-exposed value." Values like VITE_SUPABASE_URL and VITE_SUPABASE_PUBLISHABLE_KEY "are embedded into the client bundle at build time and are safe to be public." (Lovable: Secrets)

Do:

  • Open .env in Lovable's code editor and confirm it holds only VITE_ values that are meant to be public.
  • Put payment keys, AI provider keys and service credentials in Secrets.
  • For a quick review, Lovable suggests this prompt: "Review frontend code for exposed secrets, API keys, or sensitive information."

Lovable-specific: don't add .env to .gitignore. Lovable says "Lovable needs .env committed to the repository" for previews and published builds. That's why it must never hold a secret.

If a secret did reach the frontend or the repo, treat it as leaked and rotate it. The order is in step 5 of our deeper checklist.

4. Check your storage buckets

In More → Cloud → Storage, each bucket shows Private or Public. Private is the default, and Lovable blocks public buckets by default on all plans. A public bucket means "files are accessible by anyone with the URL." (Lovable: Storage)

Do: for each public bucket, ask whether anything in it belongs to one user, like invoices, IDs or uploads. If so, make it private and serve files with signed links. Our guide Is my Supabase storage bucket public? covers the policies and what breaks when you switch.

5. Turn on leaked-password protection

If your app uses email and password sign-in, Lovable can reject passwords that appear in the Have I Been Pwned database. On Lovable Cloud, enable Password HIBP check in More → Cloud → Users → Auth settings → Email. On your own Supabase project, use Supabase's leaked password protection setting. (Lovable: Security overview) The Quick scan also flags "leaked-password protection turned off."

6. Decide who can open the project and the live site

Lovable has two separate settings, and they don't affect each other (Lovable: Project access):

  • Project access decides who can open the project in the editor, including source code and chat history.
  • Website access decides who can visit the published URL.

Website access is set in the publish dialog (Who can view your site?). The Workspace option is for Business and Enterprise plans only; Free and Pro use Invite only. (Lovable: Publish)

Do:

  • For an internal tool, follow Lovable's advice: "Set project access to workspace," "Verify the app is not published publicly," and "Require authentication even for internal tools."
  • For a public app, check that only the people you expect can edit the project.

7. Test the live app while logged out

Lovable is clear that the browser can't be trusted: "Frontend code should never make security decisions," and "All authentication decisions must happen server-side." (Lovable: Security best practices)

Do:

  • Open the published URL in a private window.
  • Open a few private pages directly. You should be sent to sign in and see no data.
  • For the database itself, run the logged-out API test in step 4 of our deeper checklist. Only run it on your own app.

8. After you publish, keep scanning

Lovable: "Security is an ongoing process." Run the Deep scan again whenever you add features, change sign-in, change data access or add an integration. Every new table needs its policies before it holds real data.

If your Lovable project uses your own Supabase project, note that from Oct 30, 2026, Supabase will require an explicit grant before the Data API can see new tables you create in the public schema of existing projects (projects created since May 30, 2026 may already work this way). Existing tables keep their grants. Lovable's docs don't say whether this change reaches Lovable Cloud databases, so on any project, if a new table returns a permission denied (42501) error, check its grants before you change its RLS policies. The safe fix is in our 42501 guide.

FAQ

Is Lovable's security scan enough on its own?

Lovable says its tools "do not replace a thorough security review" and suggests an additional professional review for apps handling sensitive data. The scans are a good first step. The two-account and logged-out tests above check what they can miss in your specific app.

Is my Supabase publishable key in .env a problem?

No. Lovable says VITE_SUPABASE_PUBLISHABLE_KEY is "safe to be public." Your RLS policies protect the data. Only secret keys must stay out of the frontend.

Does auto-fix replace these checks?

No. Lovable's auto-fix handles some Quick scan findings during build requests (it consumes credits), and "it does not apply fixes for Deep scan findings."

Do these checks apply if I connected my own Supabase project?

Yes. Policies, storage and auth settings live in your Supabase dashboard instead of More → Cloud, and secrets are managed in Supabase. (Lovable: Connect to Supabase, Lovable: Secrets)

Want a second pair of eyes?

Free check: A passive check of your public homepage, its scripts and its security headers, and nothing else: we look for exposed secret keys, missing headers and public storage links found in the code (the bucket itself is never opened or listed). No database queries, no logins, no changes. One page, within 24 hours. Owners only. Request a free check

Rather have it done? Security Fix ($149) covers RLS, public storage holding private files and exposed keys in your Lovable app. Within 48 hours of working access or a full refund (Refund Policy). See Security Fix

Sources

  1. Lovable: Security overview (Quick vs Deep scan, publish dialog, "do not replace a thorough security review", leaked password protection, auto-fix limits).
  2. Lovable: Project security view (Critical/Warning labels)
  3. Lovable: Security best practices (RLS location and pre-publish checks, frontend and auth rules, workspace security, "ongoing process")
  4. Lovable: Secrets (Secrets vs VITE_, .env must be committed)
  5. Lovable: Storage (Private/Public, public blocked by default)
  6. Lovable: Project access (project access vs website access)
  7. Lovable: Publish (website access in the publish dialog, plan options)
  8. Lovable: Connect to Supabase (own Supabase project: backend, storage, auth settings and secrets managed in Supabase)
  9. Supabase changelog: Tables not exposed to Data and GraphQL API automatically.