How AI Coding Agents Are Redefining Automation
How the Zapier SDK and Notion Workers are evolving visual no-code builders into coding agents that write, deploy, and version integrations in minutes.
Your vibe-coded Lovable app works, which is kind of the problem.
Lovable makes it possible to build an app quickly, but a working interface can hide exposed customer data. This article explains why experienced security review matters and outlines checks for database permissions, storage and unnecessary data collection.
Nobody hacked 23,000+ Lovable sites. They didn’t know they needed to lock down their own databases.
I enjoy building with Lovable. It's one of the best things to happen to small teams in years: describe what you want in a few sentences, and a working app (sort of) shows up.
So it pains me (a little) to write this post.
The dangerous thing about a vibe-coded app is that it works and looks finished: the form submits, the dashboard loads, the client is happy. There's no error message that says "by the way, anyone on the internet can read your customers’ data."
What the researchers found
A German security firm, Crissy Field, pulled 159,041 Lovable projects out of the Common Crawl web archive and asked a simple question of each one: what will your database hand over to a complete stranger?
Research by Crissy Field
The app worked. The database was open to anyone.
Researchers asked one question of every Lovable project they could find in the public web archive: what will your database hand over to a stranger who isn't logged in?
What they scanned
159,041Lovable projects found in Common Crawl
34,545running on Supabase, Lovable's default database
~24,000with no login protecting their data
Bars drawn to scale against all projects found. The last figure is roughly 7 in 10 of the Supabase projects.
7 in 10
Supabase-backed Lovable apps would answer a direct database request from anyone on the internet. No hack needed, and no error message to warn the owner.
No loginProtected
What anyone on the internet could read
Every item below was readable without logging in. Nobody broke in to get it.
Exposed
7,403
sites exposing customer email addresses
Across the scanned projects
Exposed
1,000+
passport records
One service provider
passport no.expiry datenationality
Exposed
200,000+
chat messages, plus 80,000 user profiles
A lifestyle forum
Exposed
Tens of thousands
orders and tickets
Event organisers and restaurants
namesphone numbersaddressespayment detailsticket codes
Exposed
AI-generated summaries of internal emails about tenants and owners
A property management company
The answer was, to put it gently, a lot.
- Roughly 7 in 10 of the 34,545 projects running on Supabase (the database Lovable uses by default) had no login to protect its data.
- Email addresses were readable on 7,403 sites.
- One service provider's database coughed up over 1,000 passport records, expiry dates and nationalities included.
- Event organisers and restaurants exposed tens of thousands of orders and tickets: names, phone numbers, addresses, payment details, ticket codes.
- A lifestyle forum leaked 200,000+ chat messages and 80,000 user profiles.
- A property management company exposed AI-generated summaries of internal emails about tenants and owners.
The leaked data belonged to customers, not to the founder who built the app over a weekend. These were people who typed a passport number into a form because a business asked them to, and who reasonably assumed someone had thought about where it would go.
Nobody was “hacked”
This wasn't a hack. Lovable wasn't breached. An easy-to-use platform doesn't remove the need for someone who knows what they're doing to review access permissions before an app touches confidential data.
Tools like Lovable have made building cheap. Knowing what to check still takes someone who understands software engineering practices.
An experienced builder won't outgrow Lovable. What they add is a short list of boring, unglamorous questions, resolved before launch rather than after a journalist emails you for a comment on the latest data breach:
- Who should be able to read this data? Who should be able to change it?
- What happens if someone who isn't logged in calls the database directly?
- Do we even need to store this, and for how long? (a passport number you never collect is a passport number you can never leak)
- What's sitting in file storage, and is that bucket public?
None of that is hard. It just has to be someone's job. If you’re not a software engineer, this list could look exhausting.
If you've built something on Lovable, check this today
You don't need to panic, and you don't need to hire anyone to do the first pass. Here's the fifteen-minute version:
- Open your Supabase project and look at every table. Each one should have RLS switched on. Supabase's Security Advisor will flag the ones that don't.
- Read the RLS policies, not just the toggle. RLS that's "on" with a policy allowing everyone to select everything is the same as RLS that's off.
- Test it as a stranger. Log out, open an incognito window, and try to get at data that isn't yours. If you can, so can everyone else.
- Check your storage buckets. Uploaded contracts, IDs and photos live there, and "public" means public.
- Delete what you don't need. If the app collected it "just in case", that case has now arrived.
- Run the built-in Lovable security scans before you publish, then treat a clean result as a starting point, not a certificate.
If any of those made you go "hmm?", that's your sign to reach out to us.
How we can help
At workFlowers, we build Lovable apps and internal tools for small teams, alongside automations and systems using Notion and Zapier. We're not here to talk you out of these tools. We're here so that when your app goes live, the questions above have already been asked and answered by someone whose job it was to ask them.
That looks like one of two things:
- We build it with you. Same speed you'd get on your own, with access rules, storage and data handling set up properly from day one.
- We review what you've already built. You keep your app. We go through the database rules, the storage, the integrations, and tell you plainly what's exposed and how to fix it.
If you've shipped something and you're now not entirely sure who can see what, get in touch.
A few years ago I wrote that technology doesn't progress; people do. I still think that's right. The tools have come a long way. The judgement about what to do with them still has to come from a person.
Related Posts
I'm Not Vibe-Coding the Next Salesforce
Five small, purpose-built apps I vibe-coded to replace SaaS tools, fix the missing 10% of off-the-shelf platforms, and stop the recurring bills.
Can you afford to lose track of your contracts?
Streamline your contract management and save thousands with our automation solution using Zapier and Notion for small businesses