Fix: Lovable × security
Your Lovable app shipped fast.
Its data might be shipping too.
A public scan found 303 publicly reachable endpoints across 170 Lovable-built sites leaking personal data, payment details, and API keys. That is not a reason to throw away what you built — the frontend is usually fine. It is a reason to put a backend under it where tenant isolation, sessions, and secrets are enforced by code you never had to remember to write.
The problem isn't Lovable. It's everything Lovable leaves to you.
Lovable generates a polished React frontend wired to Supabase — which means your app's entire security model lives in Row Level Security policies that the AI may or may not have written, and that you may not know exist. Security researcher Matt Palmer's scan of 1,645 Lovable apps found 170+ with their database fully readable by anyone, and a vibe-eval.com audit found 90% of scanned apps sharing the same five vulnerabilities. The pattern was severe enough to earn its own CVE (CVE-2025-48757). A developer with 20+ years of experience posted an open letter about Lovable app security to r/lovable and collected 620+ upvotes — the community knows. The uncomfortable part: you asked for features, and you got them. Nobody asked for the security policy on every table, so nobody wrote it.
Five things to check in your Lovable app today
RLS disabled or default-open
Open Supabase → each table → check Row Level Security. If it's off, every row is readable with the anon key that ships in your frontend. This was the root cause in the majority of exposed Lovable apps.
Keys visible in the bundle
Open your deployed site, view source, search for 'sk_', 'service_role', and 'api_key'. Anything you find, an attacker found first. Rotate immediately — deleting the code doesn't un-leak the key.
The anon key doing privileged work
If any client-side call inserts, updates, or deletes without an RLS policy scoping it to the signed-in user, any visitor can do the same with curl. The UI hiding the button is not access control.
Edge functions without auth checks
Lovable-generated edge functions often trust that only your frontend calls them. They're public URLs. Each one needs to verify the caller's JWT before touching data.
Auth flows nobody tested past the happy path
Sign-up works. But does a password reset invalidate the link after use? Can a deleted user's session still call the API? These are the questions no prompt asked.
What a wall looks like when you can't forget to build it
In useDeploy, tenant isolation isn't a policy you write per table — it's the repository layer itself. Every repo is org-scoped and a Prisma query guard checks the organization on every query. A request for another org's resource doesn't get a permission error that confirms the resource exists. It gets a 404, as if it never did.
1 $ curl api.yourapp.com/api/orgs/org_b/projects # session belongs to org_a
2 HTTP/1.1 404 Not Found
3 { "error": "Not found" }
4
5 # server log
6 WARN tenant-guard: session org_a requested resource in org_b
7 INFO responded 404 — existence not disclosed
8
9 # there is no RLS policy to forget. the guard runs on every query.
Already closed on the base
Tenant isolation without RLS
Org-scoped repositories plus a Prisma query guard mean cross-org access returns 404 by construction. There's no per-table policy checklist, so there's no policy to miss.
Sessions live server-side
Sessions are rows in Postgres, revocable at will — not tokens the client holds forever. Ending concurrent sessions on a credential change is a documented flag you flip, not a rewrite.
Secrets never reach the browser
Every secret lives in environment variables validated by a Zod schema at boot. If a required secret is missing, the server refuses to start — and nothing secret is ever bundled client-side.
Auth that's more than a form
2FA TOTP, magic links, and OAuth ship wired through BetterAuth, with rate limiting on auth endpoints by both IP and email so credential stuffing hits a wall.
Proof, not vibes
450+ automated tests and a Playwright E2E gate in CI mean the security behaviors above are exercised on every merge — including the cross-org 404.
Migration path: keep the frontend, rebuild the floor
Lovable syncs your project to GitHub, so start by exporting the repo — your React components, pages, and styling largely survive. What changes is what they talk to. Direct Supabase calls from the browser become calls to a typed API: useDeploy exposes every endpoint through generated OpenAPI types, so your components fetch through a client that catches drift at compile time. Auth moves from Supabase Auth to BetterAuth (cookie-based sessions, 2FA and OAuth included), and your tables move into a Prisma schema where the tenant guard scopes every query. Do it screen by screen: point one page at the new API, verify, move on. The app your users see barely changes. The part they couldn't see — the part that was leaking — is what gets replaced.
Lovable × security, asked directly
Can I keep my Lovable frontend?+
Do I still need to learn RLS?+
What happens to my existing Supabase data?+
How do I know the base itself is secure?+
One license. Two ways to own it.
CORE
Founder
A frozen snapshot of UseDeploy. Yours forever, no updates.
- Frozen-version zip download
- Full source, commercial use, unlimited projects
- All 800+ tests · all docs pages
- 14-day refund
LATEST + UPDATES
Lifetime
Always the latest UseDeploy. Re-download every release, free.
- Latest-version zip — re-downloadable forever
- Every future release at no extra charge
- Priority Discord support
- All 800+ tests · all docs pages
- 14-day refund
Give the app the backend it deserved
You proved the product in days. Now put a floor under it: tenant isolation, server-side sessions, and validated secrets — already built, already tested.