Why Vibe Coding Projects Get Hacked (And What to Audit Before You Ship)

Here’s a number that should give you pause: 48 days. That’s how long Lovable, one of the most popular AI app builders, left user project data exposed due to a misconfigured database. It wasn’t a sophisticated attack. It was a basic configuration mistake, the kind that gets made when you’re shipping fast and skipping the boring parts.

If you’ve used a vibe coding tool to build your product, you’re not immune to this. In fact, you’re probably at higher risk, because you didn’t read every line of code that went into your app. Neither did I. That’s the point of these tools. But “I didn’t write it” is not a defense when your users’ data leaks.

This post is for founders who built something real with AI tools and are about to (or already did) put it in front of real users. Here’s what to audit before you ship. Or before it’s too late if you already did.

Why Vibe-Coded Apps Have a Security Problem

AI code generators are optimized for “it works.” They are not optimized for “it’s secure.” When you prompt an AI to build a user authentication system, it will produce something that functions. It will not necessarily produce something that handles edge cases, validates inputs correctly, or follows the principle of least privilege. It will look like code written by a junior developer who has read a lot of Stack Overflow, but never shipped a production app that got attacked.

The Lovable situation wasn’t unique. It was predictable. When you build fast with tools you don’t fully understand, security gaps appear at the seams: between your frontend and your database, between your API and your auth layer, between what you assumed the tool configured and what it actually did.

The good news: most of these gaps are findable without being a security engineer. You just have to look.

The Pre-Ship Security Audit Checklist

1. Check Your Database Rules (This Is the Lovable Problem)

If you’re using a backend-as-a-service like Supabase, Firebase, or similar, your database almost certainly has access control rules. These rules define who can read or write what data. The default settings on many of these platforms are dangerously permissive during development, because that’s convenient for building.

Before you go live, open your database settings and look at the rules. Can an unauthenticated user read your users table? Can any authenticated user read another user’s data? If you’re not sure how to read the rules, paste them into your AI tool and ask: “Are there any rules here that would let a logged-in user access another user’s data?” That’s a useful gut check.

2. Audit Your Environment Variables

Your API keys, database credentials, and secret tokens should never be in your frontend code. If they are, they’re public, because anyone can open browser dev tools and find them.

Check your repository for any file that contains the word “secret,” “key,” or “token.” Check whether your frontend code is making direct calls to your database or third-party APIs using credentials that are visible in the network tab. If you see something like supabaseKey or apiSecret hardcoded in a JavaScript file that gets shipped to the browser, that’s a problem.

Also: check your .gitignore. Make sure your .env file is in it. Then check your git history to make sure you didn’t accidentally commit it before adding it to .gitignore. Yes, git history is public if your repo is public. Yes, people scan for this.

3. Verify Authentication Is Actually Enforced

This sounds obvious, but AI-generated apps sometimes build authentication that works on the frontend but doesn’t actually protect the backend. Your app might redirect unauthenticated users away from a dashboard in the browser, but if your API endpoints don’t independently verify the user’s identity, someone can call those endpoints directly and bypass your frontend entirely.

Test this yourself: open your browser’s network tab while using your app. Find an API call that fetches user-specific data. Copy that request as a curl command. Remove or modify the authorization header. Send it. Did it still return data? If yes, your backend is not enforcing auth.

4. Check What Data You’re Actually Storing

AI tools are helpful but they sometimes over-collect. Look at what your app is actually sending to your database. Are you storing the full response from a third-party API when you only need two fields? Are you logging user inputs that you never intended to log? Are you storing passwords in plain text because the AI-generated code skipped hashing?

Open your database and look at a real record. Ask yourself: if this table leaked, how bad would it be? The answer to that question should inform how urgently you fix what you find.

5. Review Your Third-Party Integrations

Every API you connect to is a potential attack surface, not because of the provider’s security, but because of how you’ve integrated it. Are you passing user data to a third-party service that doesn’t need it? Are you using a webhook that doesn’t validate the incoming request is actually from the expected source? Are you storing OAuth tokens in a place that’s accessible to the wrong people?

List every external service your app talks to. For each one, ask: what data am I sending, what am I storing from the response, and who has access to those stored values?

6. Run a Basic Dependency Scan

The packages your AI tool pulled in might have known vulnerabilities. This is not a hypothetical risk. It’s a common one.

If you’re using Node.js, run npm audit. If you’re on Python, run pip-audit or use Snyk’s free tier. This takes five minutes and will surface anything obviously broken. You don’t need to fix everything, but you should know what you’re carrying.

7. Check Your Hosting Configuration

Many vibe-coded apps get deployed to Vercel, Netlify, Railway, or similar platforms with the defaults left on. Some of those defaults are fine. Some are not. Specifically:

• Is your app accessible over HTTPS only? (It should be.)
• Are there any admin routes or internal tools that are publicly accessible?
• Do you have any storage buckets (S3, Supabase Storage, Cloudflare R2) that are set to public read when they shouldn’t be?

Storage buckets deserve special attention. A misconfigured bucket is one of the most common causes of data exposure, and it’s not always obvious because the data is still “there” and the app still works fine. You just also happen to be serving it to anyone on the internet who guesses the URL.

8. Get Someone Else to Try to Break It

This is the step people skip because it feels embarrassing. Don’t skip it. Find a technical friend, offer them a coffee (or $50), and ask them to spend an hour trying to access data they shouldn’t be able to access. You will be surprised what a second pair of eyes finds in 60 minutes.

The Uncomfortable Truth

Security is not a feature. It’s not something you add later. Every week you’re live with a misconfigured database or an exposed API key is a week you’re gambling with your users’ trust.

The founders who got burned by incidents like the Lovable breach weren’t careless people. They were just moving fast and assuming someone else had handled it. With vibe coding tools, no one handles it. The AI generates the code. The platform deploys it. The founder hits publish. And then they wait to find out whether anything bad happens.

You don’t have to be a security expert to do this audit. You have to be willing to spend a few hours being honest with yourself about what you shipped. Do that before someone else does it for you.