Building a product with an AI app builder is a legitimate way to start a company. A founder can go from idea to paying customers in weeks. The risk is not the tool. It is that the moment you take sign-ups, payments or customer files, you hold other people’s data, and the generated app may not protect it the way you assume.
This guide is for founders and small teams who built with Lovable, Bolt, Replit, Cursor, v0, Claude Code or similar tools and are about to launch, or already have. It explains what goes wrong, and gives you a checklist you can work through in an afternoon.
What researchers keep finding
The evidence is consistent across independent studies:
- Escape (October 2025) scanned 5,600 publicly reachable vibe-coded apps and found more than 2,000 vulnerabilities, over 400 exposed secrets and 175 cases of exposed personal data, including medical records and bank details. Its scans were passive, so these are minimums.
- RedAccess, reported by Axios (May 2026), found around 380,000 publicly reachable assets built on popular AI app platforms. About 5,000 of them held sensitive data, from patient conversations to internal corporate documents.
- UpGuard (October 2026) examined about 300,000 domains using Supabase and found 16,326 databases with tables anyone could read. More than half of those exposed personal data. Its key finding: tables created programmatically, which is how coding agents usually work, do not get row-level security by default.
Individual cases tell the same story. In 2025 a researcher analysed 1,645 apps built with Lovable and found 170 that let anyone read or write their database without logging in. The issue was recorded as CVE-2025-48757, which Lovable disputes. Wiz found that the Base44 platform let anyone register for a private app using only an ID visible in its URL; it was fixed within a day. And in July 2025 an AI agent on Replit deleted the production database of an app being built by SaaStr founder Jason Lemkin, during a code freeze.
Why it happens
Many AI-built apps follow the same design. The front end runs in the visitor’s browser and talks directly to a hosted database such as Supabase or Firebase, using a key that ships with the app. That key is meant to be public. What protects your data is a separate set of rules in the database that decide who can read and write each row.
If those rules are missing or too loose, the public key is all an attacker needs. They do not have to break anything. They just ask the database for the data, the same way your app does.
The tools are getting better at this, but generated code optimises for “it works”, and an app with no access rules works perfectly in a demo.
The pre-launch checklist
Work through these in order. The first four cover most of the serious findings in the studies above.
1. Turn on database access rules for every table, and test them
On Supabase, enable row-level security (RLS) on every table in an exposed schema. On most projects, tables you create in the dashboard get it by default; tables created with SQL or through the API do not. Then write policies, because RLS with no policy blocks everything, and a policy that only checks “is someone logged in” lets every user read every row.
Test it for real: try to read each table without logging in, then logged in as a second test user. Run Supabase’s built-in Security Advisor, which flags tables with RLS disabled, exposed user data and views that bypass RLS. On Firebase, never ship the “test mode” rules; Google’s own documentation says never to use them in production.
2. Keep secret keys out of the browser
Supabase’s publishable (anon) key is designed to be public. Its secret and service_role keys bypass RLS entirely, and Supabase warns that a leaked secret key exposes all of your project’s data. The same applies to payment, email and AI provider keys.
Open your deployed site, view the page source and the JavaScript files, and search for secret, service_role, sk_ and your providers’ key prefixes. Run Gitleaks over your repository history, because a key that was committed once and deleted later is still in the history. If you find one, rotate it; deleting it is not enough.
3. Check that one customer cannot see another customer’s data
Broken access control is the number one risk in the OWASP Top 10 for 2025, and GitHub reported it overtook injection as the most common code-scanning alert in 2025. In practice it looks like this: you log in, open your invoice at /invoices/1042, change the number to 1041 and see someone else’s.
Create two test accounts and try exactly that on every page and API call that takes an ID, including file downloads and admin screens.
4. Require login on every server function and API route
Edge functions, serverless routes and webhooks are easy to forget because nothing in the user interface points to them. List them all and confirm each one checks who is calling and whether they are allowed to. Pay special attention to sign-up, password reset and one-time-code endpoints. The Base44 flaw was in its sign-up and one-time-code verification endpoints.
5. Make storage buckets private
Files in a public bucket can be read by anyone who has the link, and links leak through emails, logs and browser history. Put ID documents, contracts, invoices and anything personal in a private bucket with access rules, and serve them through short-lived signed links.
6. Verify payment webhooks
If your app grants access or credits when a payment provider calls a webhook, check the request really came from them. With Stripe, verify the Stripe-Signature header against your endpoint secret using the raw request body. A common mistake is parsing the body as JSON before verification, which makes the check fail or get switched off.
7. Check every dependency is real and the one you meant
AI tools sometimes suggest packages that do not exist. In a study presented at USENIX Security 2025, about 20% of the packages recommended across 576,000 generated code samples were made up, and many of the same fake names came up again and again. Attackers register those names and wait. This is known as slopsquatting.
Check each new package exists, has real usage and is spelled correctly, then run OSV-Scanner on your lockfile to catch known vulnerabilities.
8. Add rate limits where abuse costs you money
Login, password reset, one-time codes, contact forms and anything that calls a paid AI model should limit how often one person can use it. Without limits, attackers can guess passwords, spam your users or run up your AI bill overnight. OWASP lists this as “unrestricted resource consumption”.
9. Separate development from production, and test your backups
Give the AI agent a development database, not your live one, and give it the least access it needs. Keep backups you have actually restored at least once. The Replit incident ended well only because rollback worked, even though the agent said it could not. That is not a plan.
10. Run the platform’s scanner, then go one step further
Lovable, Bolt, Replit and Supabase now all include security checks, and you should use them. They also say plainly what they are: Lovable says its scans cannot guarantee complete security and suggests a professional review for apps handling sensitive data, and Bolt calls its audit a first pass. Add an outside-in check with free tools such as ZAP’s baseline scan or Nuclei, which look at your live app the way an attacker would.
When to get an expert review
The checklist covers the common failures. An independent review is worth it when:
- you are about to take payments, health data, financial data or children’s data
- an enterprise customer sends a security questionnaire or asks for a penetration test
- you are raising money and investors ask about security
- your app lets users upload files, connect accounts or trigger actions in other systems
Mirawyn’s AI-built app security review tests your app the way an attacker would, using the same open-source tools named here plus manual testing, and gives you fixes your AI tool can apply. For teams that keep shipping with AI, an AI code assurance pipeline runs these checks on every change automatically.
Sources
- Escape, “Methodology: 2k+ vulnerabilities in vibe-coded apps”, 29 October 2025. escape.tech
- Axios, report on RedAccess research into data exposed by vibe-coded apps, 7 May 2026. axios.com
- UpGuard, research on systemic data exposure in Supabase apps, October 2026. upguard.com
- NIST National Vulnerability Database, CVE-2025-48757. nvd.nist.gov
- Matt Palmer, statement on CVE-2025-48757 and the original research. mattpalmer.io
- Wiz Research, critical authentication bypass in Base44, 29 July 2025. wiz.io
- The Register, Replit’s response to the SaaStr database deletion, 22 July 2025. theregister.com
- Fast Company, what happened when Replit’s agent wiped the database, July 2025. fastcompany.com
- Supabase documentation, row-level security, API keys and database advisors. supabase.com, API keys, advisors
- Firebase documentation, insecure security rules. firebase.google.com
- OWASP Top 10:2025. owasp.org
- OWASP API Security Top 10 2023. owasp.org
- GitHub, Octoverse 2025, 28 October 2025. github.blog
- Stripe documentation, webhook signatures. docs.stripe.com
- Spracklen et al., “We Have a Package for You!”, USENIX Security 2025. usenix.org
- Lovable documentation, security. docs.lovable.dev
- Bolt, security audit on publish, 30 July 2026. bolt.new