A 5-minute guide to checking whether your Lovable / Bolt / Replit app is leaking your users' data, and why it probably is.
I've been fixing apps built with AI tools like Lovable, Bolt, Replit, and Cursor, and the same handful of serious security holes shows up in almost every one. Not because the founders did anything wrong, but because the tools optimize for "make the demo work," not "keep your users' data safe."
To show what I mean, I built a small task manager the way a non-technical founder would: describe it to the AI, wire up Supabase for the database and login, ship it. Standard stack, standard prompts. Then I ran a security pass over it.
Five critical issues. Plus three more. Before I had written any code myself.
And this isn't just my one demo app. When Escape.tech scanned 5,600 real production apps built this way, 1,400 had vulnerabilities and they found over 400 leaked secrets. A separate audit of 200+ apps found 91.5% had at least one AI-generated security flaw. This is the norm, not the exception.
Here's what was wrong with mine, and exactly how you can check your own app for the same things. Most of these take a minute and need nothing but your browser.
1. The database was readable by anyone with a browser
This is the big one, and it's everywhere. Supabase ships new tables with row-level security off by default. That means the public key sitting in your app's frontend, the one every visitor's browser downloads, can read every row of every table. In my app, that included every user's email and password.
Check yours: if you're technical, open your Supabase dashboard and look at whether RLS is enabled on your tables, and whether the policies actually scope rows to the logged-in user. If you're not technical, this is the single most important thing to have someone verify.
2. The admin key was shipped to the browser
To "fix" a permissions error, AI tools will sometimes drop the service_role key into the frontend. That key bypasses all security rules. Anyone who opens developer tools and views the page source can find it and take full control of the database.
Check yours: open your live site, right-click, View Source, and check the loaded .js files. Search the text for service_role. If it's there, that's a five-alarm fire. Rotate that key today.
3. Third-party API keys were sitting in the frontend
My app had its OpenAI key exposed in the browser bundle. Anyone can lift a key like that and run up thousands of dollars of charges on your account.
Check yours: in that same page source, search for sk-, sk_live_, or AIza. Those are OpenAI, Stripe, and Google key prefixes. None of them should ever be visible in your frontend.
4. The admin panel was "hidden," not protected
The app checked whether you were an admin in the browser, a single line of JavaScript. But the server did no such check. Anyone could open devtools, flip that flag, and walk straight into the admin view. The same pattern lets a normal user read another user's data just by changing an ID in the URL.
Check yours: this one needs a developer, but the tell is simple. Protection that lives only in the interface (a hidden button, an isAdmin flag) and not on the server is not protection at all.
5. No rate limiting, no security headers, no tests
The password-reset endpoint could be hit thousands of times a second with no throttle. The app sent none of the standard security headers browsers look for. And there wasn't a single automated test, which means every "quick change" risks silently breaking something that was working.
Check yours: securityheaders.com will grade your headers for free in a few seconds.
Why this keeps happening
None of this is a knock on AI builders or the people using them. These tools are genuinely remarkable at getting an idea to a working prototype. But they generate the happy path, the version where everything goes right and no one's trying to break in. Security, permissions, and error handling are the invisible 20% they consistently skip, because you didn't ask for them and the demo works fine without them.
The problem is that "the demo works" and "it's safe to put real users on it" are two very different bars, and the gap between them is exactly where the data leaks live.
If you want a hand
If reading this gave you a bad feeling about your own app, that instinct is usually right.
Free safe scan. Email your app's live URL to [email protected]. That is all I need. Within 48 hours I reply with what your app exposes to anyone on the internet: keys sitting in your frontend, missing protections, and whether your database looks open from the outside. I only look at what any visitor's browser already downloads, so there is no login, no database access, and nothing invasive, and I only ever scan the URL you send me.
Want the full picture? The paid diagnostic goes deeper. I review your app and code, find every issue like the five above, rank them by severity, and send a written report with a fix estimate for each. It is yours to keep whether or not you hire me for the fixes. Fixes come as a pull request you review and merge, and I never touch your production without your say-so.
Either way, check for these five. Your users are trusting you with their data, and right now there is a good chance it is sitting in the open.
Mike I., [email protected]
SOCIAL SHARE CARD GENERATOR