Lovable App Audit

Not by default. Lovable generates working React and Supabase code quickly, but security depends on configuration it does not enforce. The most common problems we see are Row Level Security that is off or written permissively, and permission checks placed in React rather than in the database, where any user can bypass them.

Two incidents have been widely reported. In 2025, CVE-2025-48757 described apps built on Lovable whose database tables were readable by anyone because row level security was missing or too loose; Lovable disputes it as the customer's responsibility. In 2026, Lovable reported that chat history and source code of public projects could be opened by other Lovable users between 3 February and 20 April; it says private projects and Lovable Cloud were not affected. Neither changes the main job: check your own app's database rules.

Lovable itself is a sound platform. The real question is whether the app it produced for you is production-ready, which is a different thing. Apps built quickly with any AI tool tend to ship without database constraints, indexes or monitoring. Those gaps rarely show until you have real users.

Supabase requires Row Level Security to be enabled and policies written before it protects anything. In the Lovable apps we have looked at, RLS was either disabled or enabled with policies permissive enough to let any authenticated user read any row. Enabled is not the same as enforcing.

It is one of the most common faults we find. If permission checks live in your React components rather than in database policies, a user can open browser developer tools and request the data directly. The interface hides other customers' records; the database still hands them over.

Only once someone has verified the permission model at the database level. If your app holds personal data you are responsible for it under UK GDPR, regardless of what built it. Check before you load real records, not after.

As a working demonstration, usually yes. Under technical due diligence, less often. Technical reviewers look for database structure, permission enforcement and test coverage — precisely what AI tools skip. Finding out during diligence costs considerably more than finding out now.

Performance usually degrades before anything breaks outright. AI-generated schemas rarely include indexes beyond primary keys, so queries that were instant at 100 rows crawl at 100,000. Concurrent actions can also produce duplicate reference numbers where no database constraint prevents it.

Usually not. Most of what we find is configuration and structure rather than the application logic itself, and that is fixable without starting again. A rewrite is occasionally cheaper, but that should come out of an assessment rather than an assumption.

It depends on what is wrong. Our audit is a fixed price, agreed before we start, and it tells you exactly what needs doing and what it will take. If you then ask us to do the work, the cost of the audit comes off the bill in full. Establishing the scope is the cheap part.

It can, once the permission model is enforced in the database and secrets are out of client-side code. Automated scanners will catch some of it. They cannot tell you your permission logic sits in the wrong layer, or that your schema does not match how your business works. That needs a person to read the code.

No. We need the code, which you can export to a GitHub repository from Lovable and share with us, and ideally read-only access to the Supabase project so we can inspect the database schema and the row level security policies. We do not need to log into Lovable itself, and we will not change anything in your application.

Usually not, and we have no incentive to. A Lovable application that has a sensible data model and a couple of security gaps is worth fixing, and fixing it is cheaper than rebuilding it. The cases where we recommend starting over are the ones where the database design cannot support what the business actually needs — and in those cases we will show you why rather than asking you to take it on trust. The report says what we found, including the parts that are fine.

For some things, yes, and where that is the sensible route the report will say so. The difficulty is that you have to know precisely what to ask for. Asking a generator to "make it secure" tends to produce code that looks more secure without necessarily being so, and you have no independent way of checking. The audit exists to tell you exactly what is wrong and in what order it matters, which is the part that is hard to get from the tool that wrote it.

No, and we would rather say so plainly than pretend otherwise. We build with Claude Code and Cursor, with senior developers designing the system, reviewing every change and testing it. What makes us useful here is not Lovable expertise, it is that Lovable produces React, TypeScript and PostgreSQL — which is what we have been building and fixing for years.

You get the written report within five working days of us having access to the code. Most Lovable applications are small enough that we are quicker than that. If we find something serious enough that you need to act on it immediately, we tell you as soon as we see it rather than waiting for the report.