Lovable apps with database rules that hold up once real users arrive
Review and hardening of Lovable-built apps with the weight on the database: row level security policies, secrets and keys, edge functions and the GitHub repository, then a plain recommendation to fix, rebuild part, or move.
Lovable generates a React front end and connects it to a database and sign-in, most commonly Supabase, and the platform also offers its own managed backend, Lovable Cloud. The code syncs to a GitHub repository, which is a real advantage: unlike a builder that keeps everything inside, a Lovable app can be handed to a developer and run elsewhere.
That also moves the risk. In this architecture the browser talks to the database directly, and the public key that lets it do so is public by design. The only thing between a visitor and your data is the set of row level security policies, and an AI tool will happily generate a table, a screen and a working demo without writing the policies that make it safe. Third-party scanners report finding Lovable-built apps with tables readable by anyone, and Lovable's own documentation tells you to set up row level security properly. We are describing a pattern, not a verdict on every app.
We have not published a client engagement on Lovable and we hold no partnership with it. The method is the one from our vibe code security review, applied to the layer that matters most here, which is the database.
What we build on Lovable
Row level security written for the rules you actually have
Every table gets the question of who may read, insert, update and delete a row, answered as a policy rather than assumed in a screen. Ownership by user, access by organisation and a separate, narrow route for staff are the three shapes that cover most apps. Then we test each as the wrong user and as a signed-out visitor, because an untested policy is an opinion.
Keys and secrets in the right place
The public key can be in the browser, and nothing else can. We look for service keys, payment keys and model keys in the repository, the built bundle and the project's history, move them to server-side functions, rotate any that were ever exposed, and set spend limits at the provider.
Server-side functions for anything that must not trust the browser
Prices, discounts, role changes, anything that sends email or charges money: these are computed and checked in a function the user cannot edit, not in a component the user can. Where the generated app trusted the client, we move the decision server-side and leave the screen as a view of it.
The repository made into something a team can work in
Database changes captured as migrations, environments separated so that testing does not touch live data, tests on the parts that move money or permissions, continuous integration, and a deployment you can roll back. This is the difference between an app a tool generated and an app a company can maintain.
What goes wrong on Lovable
The patterns that turn up on this platform specifically, and what we do about each one.
- 01
Tables readable by anyone with the public key
The browser's key is meant to be public, so a table without a policy is a table the internet can read, and often write. It is the most common and most expensive finding in apps like this, and the one with the quickest fix: policies, tested, before launch. We check it first and we check it by trying to read the data, not by reading the code.
- 02
A policy that exists and still lets everything through
A rule that says any signed-in user can read any row is a policy, and it protects nothing. Another that checks a column the user can also edit moves the problem rather than removing it. We read each policy for what it permits, not whether it is present.
- 03
Roles stored where the user can change them
Putting an admin flag on the user's own profile row, and letting that row be updated by its owner, is a one-line way to become an administrator. Roles belong where only the server can write them, and are checked at the database, not in the screen.
- 04
Changes made in the chat that nobody can review
Each prompt can alter code, tables and policies at once, and the history is a conversation, not a reviewable change. We put the repository and the migrations in charge, so that a change is a diff someone read, and a regression is something a test catches rather than a customer.
Where Lovable is the wrong answer
Do not rebuild a Lovable app that works, holds nothing sensitive and has five users. Hardening it is days of work and a rebuild is weeks. Equally, do not keep patching an app whose data model was shaped by a hundred conversational edits and which nobody can explain: the cheapest road is sometimes to keep the screens and rewrite the data layer behind them. The question we ask is whether someone other than the AI can say where each permission is enforced. If yes, harden. If no, the permission layer needs rewriting. Migrating a project from Lovable Cloud to a Supabase project of your own is not an automated step on Lovable's side, according to its own FAQ, so plan it as a piece of work rather than a setting.
Projects that did not use Lovable
Here for the argument rather than as evidence of Lovable work. Each one bears on a decision above, and the note says which.
Related reading
Lovable, specifically
You cannot tell from the way it looks or from the fact that it works. The first thing to check is whether every table has row level security policies that do what you intend, tested as a different user and as a signed-out visitor. Then the keys, then anything that moves money. We can do that as a written review that ends in a ranked list.
Generally yes: the code syncs to GitHub, and a front end can be deployed elsewhere. The harder part is the backend. If it uses Lovable Cloud, moving to a Supabase project you own is not an automated step, so plan it. If it already uses your own Supabase project, the move is mostly a deployment.
It can, which is why changes are made on a copy and checked against the working app before anything goes live. Tightening a policy often reveals a screen that was relying on seeing everything. Those are fixed deliberately rather than discovered by users.
You can, with a rule: changes arrive through the repository and a review, not straight onto the live database. Many teams keep using the tool for the front end and have a developer own the data layer. We will set up the repository so either way works.
No. We hold no partnership, certification or endorsement from Lovable, and nothing here should be read as one. We review apps built with it the way we review any AI-built app.
Page copy drafted with AI assistance. Skofi is accountable for it. Editorial policy
Tell us about the process that keeps costing you.
A 15-minute call is usually enough to say whether this is an automation, an integration, or something that should be built, and whether we are the right people for it.
What happens on the call
- 15 minutes, no deck
- We map the process on the call
- A written scope, or an honest no