Your Lovable app works. That's not the same as being safe to charge money on.

I built RepFlow. A CRM for medical representatives, managers and teams. Easy to use, and it can save the reps a lot of time.

After building the app and testing it for quite some time, I started to worry about safety problems. So I checked more carefully, and there was a huge list of different flags.

Three things are worth knowing before you read the rest, and none of them come from anyone selling a scanner.

In April 2026 Lovable published its own account of an incident in which backend regressions re-enabled public access to the source code and chat history of public projects. The same post says researcher reports arrived through their bug bounty and were "closed without being escalated to our internal security team", and that the company's first public response "was dismissive".

Supabase now switches row-level security on by default for tables created through the dashboard, and ships a linter that flags tables with no RLS, policies that could be more restrictive, and exposed sensitive columns. Platforms do not change their defaults over rare problems.

And in February 2026 The Register reported an independent researcher, Taimur Khan, finding sixteen vulnerabilities — six critical — in a single app featured on Lovable's own Discover page. 18,697 records, including authentication logic that blocked signed-in users while letting anonymous ones through. He called it "a classic logic inversion that a human security reviewer would catch in seconds."

Hold onto that last sentence. It is the whole point of what follows.

That's not an argument against building this way. I build this way. It's an argument that "it works" and "it's safe to take money through" are two different things, and the tools are optimised for the first one.

The part no tool does for you

Run a scanner against a real app and you get a list.

The list isn't the problem. Every line on it is one of three things:

• Real. A hole. Close it.

• A false positive. The scanner doesn't know your architecture.

• Deliberate. It looks wrong, it's meant to be there, and removing it takes your app down.

In the output they look identical.

Most production apps have all three. Working out which is which is the actual job, and it's why a checklist only gets you so far. There are at least five tools now that will hand you the list. I don't know of one that will tell you which row is which.

Two checks worth doing first

1. Read the policy, don't count the policies.

A table can have RLS on, have policies attached, and still be wide open, because the policy says true.

select polrelid::regclass as table_name,
 polname,
 pg_get_expr(polqual, polrelid) as using_expr,
 pg_get_expr(polwithcheck, polrelid) as with_check_expr
from pg_policy
order by 1, 2;

Any using_expr that just says true on a table with customer data is a hole. true passes for everybody.

The half people skip is with_check_expr. You can have a perfectly good read policy and no write constraint, which means a user can insert rows that belong to someone else. Nothing looks broken until it is.

2. Make the database prove it.

In Postgres, a new function gets EXECUTE granted to PUBLIC by default. A SECURITY DEFINER function runs with its owner's privileges. Put those together and one function you didn't know about becomes a way in.

select p.proname,
 p.prosecdef as security_definer,
 has_function_privilege('anon', p.oid, 'EXECUTE') as anon_can_run
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
order by p.prosecdef desc, p.proname;

The reason to run this isn't the output. It's that a build tool telling you "nothing else was touched" is a claim, and this is evidence.

Lovable told me it hadn't touched anything, but I didn't believe it, because everything was overlapping and it kept asking me the same question.

I had to prove to Lovable that it was wrong. It was a SECURITY DEFINER function, and it was set to public. If it stayed unnoticed, it could end up as a disaster. Personal data would be breached, and that data can be used in a lot of different and bad ways.

I was a bit shocked when I saw it. But it was also a relief that I noticed it in time, before anything happened.

The rest of the list

I put everything I check into one page. 30 checks — database, keys, auth, payments, the legal bits, and deployment. Each one shows you how to check it yourself. The SQL, the file to open, the page to load.

It runs in your browser. Stores nothing, sends nothing, no email box.

→ https://lovable-security-check.netlify.app/

The most useful thing on it is the "not sure" button. Those answers aren't gaps in your app. They're gaps in what you can prove about your app, which is a different problem, and usually the one that costs more.

Sources: Lovable, "Our response to the April 2026 incident", 22 April 2026. Supabase, "Security Retro: 2025", 7 January 2026. The Register, "Researcher finds 16 vulnerabilities in Lovable showcase app", 27 February 2026.