# Lovable security checklist for a live app

By Mark Kashef, founder of Lockpick. Published 2026-10-08, updated 2026-10-08.

What to check after you publish a Lovable app, where Lovable already helps, and what only an outside check of the live site shows.

A Lovable app is safe to share when three things hold. Secret keys stay in Lovable's Secrets, every table has access rules that match who should read it, and the published site sends nothing you did not mean to publish. Atlas, our example app at atlas.example, is the running example below.

## Where should each key live?

Lovable says its Secrets are encrypted, injected into your Edge Functions and never reach the browser. That is where payment keys, AI provider keys and email keys belong. Lovable says values prefixed with `VITE_` are embedded into the client bundle at build time and are safe to be public. So a publishable database key in the bundle is expected. A secret key in the bundle is not.

| Value | Where it goes in Lovable | Fine in the browser? |
| --- | --- | --- |
| Stripe or OpenAI secret key | Secrets | No |
| `VITE_SUPABASE_PUBLISHABLE_KEY` | `.env` | Yes, it only reaches what your access rules allow |
| A password for another service | Secrets | No |

Lovable itself says API keys and other secrets cannot be stored safely in client-side code. If a secret ever landed in your frontend code, treat it as used and replace it with the service that issued it.

## Are your access rules doing what you think?

Row level security decides which rows each signed-in person can read or change. Lovable says it sets up these rules automatically when it builds features that store user data. Review them anyway when you add a table by hand or change who can see what. The question to ask of every table is who should be able to read it without signing in. For most tables the answer is nobody.

## What does Lovable's own scan cover?

Lovable scans your project when you publish, and that scan reads your code and settings. Lovable says its own scans cannot guarantee complete security. An outside check adds a different view. It reads only what your published site shows to anyone, the way Atlas looks to a stranger at atlas.example.

## How to check the live app

1. Publish the app and copy its public address.
2. Run a [quick check](/check) on your published address to see what a stranger sees, then read [how we check](/docs/security/how-we-check) for what it covers.
3. For each thing to fix, copy the fix prompt into Lovable's chat and review the change before you publish again.

An outside check does not see your Lovable project, your Secrets or your database policies. It sees what the live site sends, which is what an attacker sees too.

## Questions people ask

### Is the publishable key in my Lovable bundle a leak?

No. Lovable puts publishable values in the bundle on purpose. It only reaches what your access rules allow, so the rules are what protect your data.

### Does Lovable check my app before I publish?

Yes, Lovable runs its own scan, and it says that scan cannot guarantee complete security. An outside check of the live site is a second, different view.

## Sources

- [Database](https://docs.lovable.dev/features/database), Lovable docs, read on 2026-10-06
- [Secrets](https://docs.lovable.dev/features/secrets), Lovable docs, read on 2026-10-06
- [Security](https://docs.lovable.dev/features/security), Lovable docs, read on 2026-10-06