Your Lovable App May Already Be Hackable!
A friend of mine reached out last week. He works in sales at a smaller company that sells market intelligence reports and analysis. He has never written a line of code in his life. But using an AI tool like Lovable Replit ChatGPT or Anthropic Cluade, he had vibe coded a custom product for one of his enterprise clients, a tailored portal where the client could log in and pull data from the company’s databases.
He was thrilled. He had onboarded more customers off the back of it, and it had taken him a couple of hours instead of the weeks it would have taken a dev team.
At first glance, the product looked great. The AI had genuinely nailed the design. A clean landing page, a clear call to action, a login portal. You signed in, and through an API call against the company’s databases, you got your data back. I tested it and I was impressed. A couple of hours of work and a real, working product.
Then, because I have spent years in software product development, I could not help but look a little closer. I used AI to run a simple penetration test on the site. And this is where the story turns.
The login page was the first problem. I created an account and became a member. Once inside the portal, there were open URLs that let me see other customers’ logins and dashboards. Not my data. Their data.
Worse, I could see the API username and password for the company’s production API. Which meant that with a few minutes of poking around, I could have built my own services on top of their live production system, using credentials that were never supposed to leave the server.
Let me be clear about what that means in plain terms. A salesperson with no coding background had, without knowing it, exposed his company’s entire customer database and handed anyone who signed up the keys to the production system. The product worked perfectly. It was also a catastrophe waiting to happen.
He had no idea. Why would he? The AI built something that looked finished, so it felt finished.
This is the part I want every product leader and every non-technical builder to sit with.
Vibe coding is easy. The AI makes the first 90% feel effortless. A landing page, a login, an API call, a dashboard. It all appears in hours, and it all looks right.
The last 10% is where production software actually lives, and it is almost entirely invisible. Authentication that actually isolates users from each other. Database rules that stop one customer from reading another’s rows. Secrets that never reach the browser. Rate limits that stop someone hammering your API. None of this shows up in the demo. All of it is the difference between a product and a breach.
The AI gave my friend a car that drove beautifully and had no seatbelts, no locks, and the keys taped to the windshield. It looked like a finished car. That was exactly the problem.
Get Danar Mustafa’s stories in your inbox
Join Medium for free to get updates from this writer.
So here are three things I would tell anyone who vibe codes, regardless of which tool you use.
The single most common failure in vibe coded apps is that the database trusts the browser. It should never trust the browser.
If you are using something like Supabase, which is a popular and genuinely good choice, the critical thing to understand is Row Level Security. By default, you have to turn it on and write policies that say who can read and write which rows. Without it, anyone who can reach your database can often read everything in it. The open URLs I found in my friend’s portal were exactly this. There was nothing stopping a logged-in user from requesting another user’s data, because no rule said they could not.
The rule of thumb: every user should only ever be able to see their own data, and that restriction has to be enforced on the server or in the database, never in the frontend code. If the only thing stopping a user from seeing someone else’s dashboard is that the link is hidden, it is not protected. Hidden is not secure.
Production credentials should never appear in anything the user’s browser can reach. In my friend’s app, the production API username and password were sitting in the frontend, which meant anyone could read them.
Two things to get right. First, secrets belong in environment variables on the server, never in the client code the browser downloads. If a key is in the frontend, assume it is already public. Second, never hand out your real production keys for a new project. Create a separate, scoped key for each use, and always set a rate limit so that even if a key does leak, someone cannot make a million requests against your system before you notice. A leaked key with a tight rate limit is a problem. A leaked production key with no limit is a disaster.
The simple version: treat every API key like a house key. You do not tape your house key to your front door, and you definitely do not hand out copies of the master key when a spare would do.
This is the part I find genuinely encouraging. The same AI that helped build the vulnerable app is very good at finding the holes in it, if you ask.
If you do not have a security team, ask your AI tool to run a basic penetration test on what you have built. Ask it directly: what are the security vulnerabilities in this app? Can a logged-in user access another user’s data? Are any secrets exposed to the client? Is anything unprotected that should require authentication? It will not catch everything a real security engineer would, but it will catch the obvious, dangerous, common mistakes, which is exactly the category my friend fell into.
Run this before you ship, not after. It takes minutes. It is the cheapest insurance you will ever buy.
I am not writing this to scare people away from vibe coding. My friend built something genuinely useful and won business with it. That is real, and it is a good thing.
But building something that works and building something safe to put in front of customers are two different skills, and AI has made the first one easy while leaving the second one just as hard as it always was. The danger is that the polished result hides the gap. It looks done, so nobody checks.
If you are a product leader whose teams are starting to vibe code, this is the conversation to have now, before something ships that should not have. And if you are building things yourself with AI, treat security as a required step, not an optional one. The tool will make it look finished. Making it actually safe is still your job.
The demo is easy. The trust is hard. And trust is the whole product.
Originally published at https://digitalstrategyai.substack.com.
