Vibe-coded apps (apps built mostly by prompting AI tools like Lovable, Bolt, Cursor, Replit or Claude Code) tend to share the same security problems: secret keys in the browser, databases anyone can read, access rules that only exist in the interface, and code that trusts whatever the browser sends. None of these stop the app from working, which is why they ship. Published research backs this up: a scan of more than 5,600 public vibe-coded apps found over 2,000 high-impact vulnerabilities and more than 400 exposed secrets. The good news is that most of these problems have well-known fixes, and you can check for many of them yourself in under an hour.
Why AI-built apps share the same weaknesses
AI coding tools are trained to produce code that works. Security is a separate goal, and it often isn't one the tool is given. When a database rule blocks a request during development, the quickest way to make the error go away is to loosen the rule. When a feature needs an API key, the quickest place to put it is right in the front-end code.
The research is consistent:
- Veracode's 2025 GenAI Code Security Report tested more than 100 AI models on 80 coding tasks. The generated code introduced security vulnerabilities in 45% of cases, failed to defend against cross-site scripting 86% of the time, and newer or larger models didn't do meaningfully better (Veracode).
- Escape's October 2025 study scanned over 5,600 publicly available apps built on Lovable, Base44, Create.xyz, Bolt and similar platforms. It found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets and 175 instances of exposed personal data, including medical records and bank account numbers. Exposed Supabase tokens, misconfigured APIs and missing row-level security were among the critical issues (Escape).
- Platforms themselves aren't immune. In July 2025, Wiz researchers found a flaw in the Base44 platform that let outsiders register for private apps, including internal tools, by using an ID that was visible in each app's public files. It was fixed within a day of being reported (SecurityWeek).
Here are the nine problems that come up most, and how to check for each.
1. Secret keys in the browser
What it looks like: API keys for OpenAI, Stripe, email services or your database's admin access sitting in front-end JavaScript, where anyone can read them with the browser's developer tools.
How to check: Open your live site, open developer tools, and search the loaded JavaScript files for strings like sk_, sk-, service_role, secret and api_key. Also search your code repository for the same strings.
How to fix: Move every secret to the server (an API route, server action or edge function) and call it from there. Then rotate every key that was ever exposed, because removing it from the code doesn't un-leak it. Public keys meant for the browser, like a Supabase anon key or a Stripe publishable key, are fine. Secret keys never are. We covered how leaked keys get abused in our post on the Railway breach.
2. A database anyone can read
What it looks like: In Supabase and Firebase apps, the browser talks directly to the database. If row-level security is off, or the rules allow everything, anyone with your public key can read or change every row.
How to check: In Supabase, run the Security Advisor and list tables without row-level security. In Firebase, look for rules that say allow read, write: if true.
How to fix: Turn row-level security on for every table and write a policy for each action your app actually needs. Our Supabase Row Level Security guide has the queries to check and the policies to copy.
3. Access rules that only exist in the interface
What it looks like: The admin page is hidden from regular users, but the API behind it doesn't check who's asking. Or a URL like /invoices/1042 shows one customer's invoice, and changing it to /invoices/1043 shows someone else's.
How to check: Log in as a regular user and try visiting admin URLs directly. Change IDs in URLs and API requests. Use two test accounts and try to view or edit one account's data from the other.
How to fix: Check permissions on the server for every request: is this person logged in, and are they allowed to see or change this specific record? Hiding a button is a convenience, not security.
4. Weak or incomplete login
What it looks like: Anyone can sign up for an app that's meant to be private. Email addresses are never verified. Password reset links don't expire. Login forms allow unlimited guesses.
How to check: Try signing up with a new email on an app that should be invite-only. Request a password reset and see whether the link still works a day later. Try ten wrong passwords in a row.
How to fix: Use your platform's built-in authentication rather than custom login code. Disable public sign-up for internal apps, require email verification, set short expiry times on reset links, and turn on rate limiting and multi-factor authentication where your provider offers it.
5. Trusting whatever the browser sends
What it looks like: The price, discount or order total comes from the browser and goes straight into the database. A form's "role" field can be edited to say "admin." A payment is marked as paid because the front end said so. In a 2025 scan of Lovable apps, researchers showed they could mark an order as paid without paying (details in our RLS post).
How to check: Look for any place the front end sends a price, total, role, or status that the server accepts as is.
How to fix: The server should decide anything that matters. Look up prices on the server, calculate totals there, and only mark orders paid after verifying the payment provider's signed webhook. Validate every input for type, length and allowed values.
6. Injection and cross-site scripting
What it looks like: User input rendered as raw HTML, so someone can post a comment that runs JavaScript in other visitors' browsers. Database queries built by gluing strings together, so a crafted input changes the query.
How to check: Search the code for dangerouslySetInnerHTML, innerHTML, v-html and SQL written as strings with user input added in. Try entering <script>alert(1)</script> into text fields and see what happens when the text is displayed.
How to fix: Let your framework escape output (React and similar frameworks do this by default unless you bypass it). If you must render HTML, run it through a sanitizer. Use parameterized queries or your database library's query builder, never string concatenation.
7. Public file storage
What it looks like: Uploaded invoices, ID photos, contracts or medical documents in a storage bucket anyone can list or open, sometimes with predictable file names.
How to check: Look at your storage settings in Supabase, Firebase, S3 or wherever uploads go. Is the bucket public? Can a logged-out visitor open a file URL? Can one user open another user's files?
How to fix: Make private buckets private, add storage policies that tie files to their owners, and serve sensitive files through short-lived signed URLs.
8. Packages nobody checked
What it looks like: AI tools add libraries freely, and sometimes suggest packages that are outdated, unmaintained or don't exist under that name, which attackers can take advantage of by publishing malicious packages with those names.
How to check: Run npm audit (or your language's equivalent) and look at the package list. Do you recognize every package? Is each one actively maintained and widely used?
How to fix: Remove what you don't use, update what's outdated, double-check that unfamiliar packages are the real ones, and turn on automated dependency alerts such as GitHub's Dependabot.
9. No limits on expensive or abusable endpoints
What it looks like: An AI chat endpoint, email sender or file upload that anyone can call as often as they like. The first sign of trouble is a surprise bill from your AI provider or your email account getting suspended for spam.
How to check: Find every endpoint that costs money or sends messages. Can it be called without logging in? Is there a limit on how often?
How to fix: Require login where possible, add rate limits per user and per IP address, set spending caps with your AI and email providers, and alert yourself when usage spikes.
Beyond the nine: what keeps a launched app safe
Fixing the list above closes the most common holes. Keeping the app safe after launch takes a few more habits:
- Error messages that don't leak details like stack traces, database errors or internal paths to visitors.
- Logging and monitoring, so you hear about failures and suspicious activity before your customers do.
- Backups you've actually tested restoring.
- Regular updates for your framework, packages and hosting.
Our security checklist for taking a Lovable or Bolt app to production covers these in more detail.
A one-hour self-check
If you only have an hour, do these in order:
- Search your live site's JavaScript and your code for secret keys (problem 1).
- Run your database's security advisor, or review its rules (problem 2).
- Test with two accounts: can one see or change the other's data (problems 3 and 5)?
- Visit admin pages and APIs as a regular user and as a logged-out visitor (problem 3).
- Check whether your storage buckets are public (problem 7).
- Run
npm audit(problem 8). - Set spending caps on your AI and email providers (problem 9).
If anything fails, stop adding features and fix it first. A security problem in an app with real customers is an emergency; the same problem before launch is just a task.
When to get a professional review
Do a professional review before launch if your app handles payments, health information, client documents or more than one company's data, or if you're about to sign a customer who will ask how you protect their data. It's also worth it if each AI-generated fix seems to create new bugs and nobody fully understands the codebase anymore.
Our AI-built app rescue service starts with exactly this kind of review. We go through your code, infrastructure and data access, then give you a prioritized report in plain English, whether or not you hire us for the fixes. Most AI-built apps have a solid core, so we fix the risky parts and keep what works. We also build our own security tooling for AI-generated code, Aegis, and once your app is live, our care plans keep it patched and monitored.
Book a free call and tell us what you've built and what it's built with. We'll tell you what a review would cover and what it would cost.