An application built with Lovable, Bolt or Base44 talks straight to its database from the user’s browser. That is what makes these tools so fast: no intermediate server to write, the screen queries the data and displays it. It is also what makes the application dangerous when one particular rule has not been set.
That rule has a technical name, row level security. It decides, for every record in every table, who may read it and who may change it. Without it, the database answers everyone.
What the browser actually holds
Your application carries a public key that lets it reach the database. That key is public by design: it sits in the page source, and Supabase says so plainly. It is designed to be public, on one condition, that access policies are in place behind it.
When they are not, anyone can take that key and query the database directly, bypassing your screens entirely. This is not hacking in the way people picture it: the database answers because it was asked politely and nothing told it to refuse.
The outcome is blunt. A customer table downloads in full. So does an orders table, amounts included. A users table hands over every email address you hold.
This is not hypothetical
In April 2025 a flaw catalogued as CVE-2025-48757 demonstrated exactly this mechanism on applications produced with Lovable. The defect: insufficient security policies letting an unauthenticated visitor read from and write to tables that should have been closed. Severity was rated 9.3 out of 10, and more than 170 applications were affected.
This is no outlier. Broken access control sits at the top of the application risk ranking published by OWASP, with over 318,000 occurrences in the contributed dataset. It is the most widespread defect in web development as a whole, and generation tools reproduce it faithfully.
A study published by Veracode in 2025 gives the scale: across 80 development tasks put to more than a hundred models, the code produced carried a vulnerability in 45% of cases where a safe method and a risky one were both available.
Four checks you can run yourself
The two-account test. Create two trial accounts with different data. Log into the first, open a record, note the address in the browser bar. Log out, log into the second, paste that address. If the first account’s record appears, the rule is missing.
The private window test. Copy the address of a document or image uploaded by a user, then open it in a private browsing window where you are logged into nothing. If it displays, your storage is public.
The database dashboard. In Supabase, the table list flags those with no active policy. A quickly generated project usually has several, and nobody has ever looked at them.
Roles. If your application separates an administrator from a regular user only by hiding buttons on screen, that separation protects nothing. A hidden button is still reachable by anyone who knows how to ask.
Why this happens almost every time
These tools do what they are asked, and nobody explicitly asks them to write access policies. Creating a table is a natural instruction. Writing, for that table, the rule limiting each user to their own rows is not, especially when you do not know the rule exists.
Supabase does default to caution: when row level security is switched on with no policy at all, the table becomes unreachable. The trap is the opposite case, a table created without the protection being enabled in the first place, which then stays open.
How the fix unfolds
Repair starts with an inventory: every table, every kind of record, and who should reach it under what conditions. That inventory is written in plain language, not jargon, because you are the one who has to approve the rules. Does a salesperson see their colleagues’ files? Does a customer see only their orders, or their rejected quotes as well?
Policies are then written table by table, on the database side rather than in the screen. Control no longer depends on how the request happens to be phrased.
The last step is verification. Access is replayed with test accounts to confirm that what should be refused actually is. An unverified fix is worth nothing: it was precisely the absence of verification that created the situation in the first place.
What you owe your customers if data has travelled
A personal data exposure is more than a technical incident. Where it carries a risk to the people concerned, it must be reported to the French data protection authority within 72 hours of the moment you became aware of it, and the procedure is set out on its site. The clock starts when you learn of it, not when the leak occurred.
Even where notification is not required, the incident has to be entered in an internal breach register, and that duty admits no exception.
One more reason to look into this before you are forced to: the check takes a few hours, declaring a confirmed leak takes several days and happens under pressure.
What we do
We read your application’s code and build the list of what is genuinely exposed today, with what each item means for your business. That document is in plain language, readable without technical skill, and it is yours.
You then decide the scope of the fix and receive a fixed quote. We rework the access rules one by one, we test them, and we show you how to repeat those checks yourself afterwards.