Is your Lovable app secure?

Lovable writes your front end and plugs a database behind it, Supabase or Lovable Cloud. Leaks nearly always come from where the two meet: a key in the wrong place, a table left too open. Here is what to look at, how, and what Rustine checks for you.

At a glance

1. A secret key in the front end

Everything sent to the browser can be read. Lovable says so itself: an API key can't be kept safe in client-side code. A leaked OpenAI or Stripe key is your bill.

Check it yourself

In Lovable, your keys go in Secrets, used by server-side functions. In your code, no secret key in a variable starting with VITE_: Vite copies it into the published JavaScript.

What Rustine checks

From the free scan, Rustine looks for secret keys (Stripe, OpenAI, Anthropic, service_role…) in the JavaScript your site serves. On GitHub, it spots a key in a public variable or an AI key called from the browser.

Free scanGitHub code · Solo, Pro

Sources: [1][2][3]

2. A Supabase table without RLS

Your anon key is in the front end, that's normal. But without Row Level Security, it's enough to read and change the whole table.

Check it yourself

Lovable's security scan checks RLS on every publish. In Supabase, the Security Advisor lists tables without RLS as errors.

What Rustine checks

After proof, the full audit counts the rows your anon key lets anyone read, without reading one. With Supabase connected, it reads each table's RLS state. On GitHub, it spots migrations that forget it.

Full audit · Solo, ProSupabase connected · Solo, ProGitHub code · Solo, Pro

Sources: [1][4]

3. A policy that lets everything through

To unblock a query, the agent sometimes writes a using (true) policy. RLS is on, but the table stays open to everyone.

Check it yourself

Supabase's Security Advisor shows it as a warning, “Permissive RLS policy”. When Lovable suggests a policy, read its condition.

What Rustine checks

With Supabase connected, Rustine reports every using (true) policy. The full audit sees the effect. On GitHub, it spots them in your migrations.

Full audit · Solo, ProSupabase connected · Solo, ProGitHub code · Solo, Pro

Sources: [4]

4. The service_role key in the front end

This key ignores all your rules. Pasted into the front end to “make a query work”, it opens your whole database.

Check it yourself

In your code, search for SERVICE_ROLE and sb_secret_: only in server-side functions. If it was published, rotate it in Supabase right away.

What Rustine checks

From the free scan, Rustine looks for it in the served JavaScript. On GitHub, in your public variables.

Free scanGitHub code · Solo, Pro

Sources: [5]

5. A live .env or .git

If you export your app to GitHub and host it elsewhere, a misplaced .env file or .git folder can be downloaded with your keys and your code.

Check it yourself

Open your-site.com/.env and your-site.com/.git/HEAD: you should land on an error page.

What Rustine checks

From the free scan, Rustine checks the usual .env files and the .git folder, reading only their first bytes.

Free scan

6. The deep scan never run

Lovable's quick scan runs on every publish. The deep scan, which reviews the code and looks for secrets, doesn't run by itself.

Check it yourself

Before a release that matters, run the deep scan from your Lovable project's Security view.

What Rustine checks

Rustine doesn't replace that scan. It looks at your published site from the outside, and runs a new full audit every week with Solo and Pro.

Free scanFull audit · Solo, Pro

Sources: [1]

Questions

Sources

1. Lovable, Security (documentation), read on 15/10/2026
2. Lovable, Secrets (documentation), read on 15/10/2026
3. Vite, Env Variables and Modes, read on 15/10/2026
4. Supabase, Performance and Security Advisors, read on 15/10/2026
5. Supabase, Understanding API keys, read on 15/10/2026