Vibe Coding Security: The Complete Guide to Securing AI-Built Apps

You described what you wanted in plain English. The AI built it. You clicked deploy. Your app is live.

But here's the uncomfortable truth: that app is probably full of security holes.

Vibe coding -- building software by describing what you want to an AI tool -- has made it possible for anyone to ship a web app in hours. Tools like Lovable, Bolt, Cursor, Replit, and v0 are turning non-developers into builders. But vibe coding security is an afterthought at best, and completely absent at worst.

This guide is for you if you've built something with an AI coding tool and want to make sure it's not leaking data, exposing API keys, or sitting wide open for anyone who knows where to look.

What Is Vibe Coding?

Vibe coding is a term coined by Andrej Karpathy in early 2025 to describe a new way of building software: you describe what you want in natural language, and an AI writes the code for you. You don't read every line. You don't fully understand the implementation. You just "vibe" with the AI until the result looks right.

The most popular vibe coding platforms include:

• Lovable -- full-stack app generation from prompts
• Bolt (by StackBlitz) -- browser-based AI coding with instant preview
• Cursor -- AI-powered code editor with autocomplete and chat
• Replit -- cloud IDE with an AI agent that builds and deploys
• v0 (by Vercel) -- UI generation from text descriptions

These tools are genuinely impressive. You can go from idea to deployed app in a single afternoon. The problem is that AI optimizes for making things work, not for making things secure.

Why Vibe Coding Creates Security Risks

Vibe coding security risks stem from a fundamental tension: AI models are trained to produce functional code, not secure code. When you ask an AI to "add user authentication" or "connect to my database," it will get the job done -- but it will often take shortcuts that would make any security professional wince.

Here's why:

AI doesn't think about attackers

Large language models generate code based on patterns from training data. They produce what statistically looks like correct code. They don't model threat scenarios. They don't think about what happens when a malicious user sends unexpected input, manipulates a URL, or inspects the browser's network tab.

The builder doesn't review the code

Traditional developers at least read (most of) the code they write. Vibe coders often don't. If you're not a developer, you can't spot a hardcoded API key or a missing authorization check. The AI won't flag it either -- it doesn't know it's a problem.

Default configurations are insecure

AI tools frequently use default configurations that prioritize ease of setup over security. Supabase Row Level Security (RLS) disabled by default. Firebase security rules set to open. CORS headers allowing all origins. These defaults work great for prototyping but are dangerous in production.

Speed kills security

Vibe coding is all about speed. Build fast, ship fast. Security reviews, penetration testing, dependency audits -- these slow things down. So they get skipped. The result is a growing population of live apps with exploitable vulnerabilities.

The 8 Most Common Vibe Coding Security Vulnerabilities

After scanning hundreds of AI-built applications, we've identified the most frequent vibe coding security vulnerabilities. Here's what shows up again and again.

1. Exposed API Keys and Secrets

How common: Found in over 60% of scanned apps.

AI tools routinely embed API keys, database credentials, and service tokens directly in frontend JavaScript. This means anyone can open their browser's developer tools and grab your keys.

Common culprits:

• Supabase anon keys with no RLS
• Firebase configuration objects with full database access
• Stripe secret keys (not just publishable keys)
• OpenAI API keys (leading to runaway bills)
• Third-party service tokens (SendGrid, Twilio, etc.)

2. Missing or Disabled Row Level Security (RLS)

How common: Found in over 70% of Supabase-based apps.

When an AI builds a Supabase app, it creates tables and writes queries -- but it almost never enables Row Level Security. Without RLS, anyone with your Supabase URL and anon key (which is in the frontend code) can read, modify, or delete every row in every table.

3. No Server-Side Authorization

How common: Found in roughly 50% of scanned apps.

The AI often implements "authorization" by hiding UI elements. If you're not an admin, the admin button doesn't show. But the API endpoint behind it? Wide open. Anyone can call it directly. This is not real authorization -- it's UI decoration.

4. Exposed Environment Files

How common: Found in about 15% of scanned apps.

Files like .env, .env.local, and .env.production sometimes end up accessible at the app's public URL. This happens when build tools misconfigure the output directory, or when the deployment platform serves static files from the wrong root. One exposed .env file can contain every secret your app uses.

5. Vulnerable Dependencies

How common: Found in over 80% of scanned apps.

AI-generated code pulls in npm packages without checking their security status. The AI was trained on data that may reference outdated or vulnerable library versions. Even when the package itself is fine, the AI might use it in an insecure way.

6. Missing Security Headers

How common: Found in over 90% of scanned apps.

Almost no AI-built app ships with proper security headers. Headers like Content-Security-Policy, X-Frame-Options, Strict-Transport-Security, and X-Content-Type-Options are basic protections against XSS, clickjacking, and MIME-sniffing attacks. AI tools don't add them because nobody asks for them.

7. Insecure Firebase Rules

How common: Found in roughly 40% of Firebase-based apps.

Firebase apps generated by AI frequently ship with overly permissive security rules -- sometimes literally allow read, write: if true;. This means anyone can read and write to your entire database, upload files to your storage, or invoke your cloud functions.

8. Weak or Missing Authentication Endpoints

How common: Found in about 30% of scanned apps.

When AI implements auth, it often skips critical protections: no rate limiting on login (enabling brute force attacks), no CSRF protection on forms, password reset tokens that don't expire, and session tokens stored in localStorage instead of HttpOnly cookies.

The Vibe Coding Security Checklist

Use this checklist to audit your AI-built application. Every item here is something we've seen fail in real apps.

How to Secure Your Vibe-Coded App

Knowing the risks is step one. Here's how to actually fix them.

Step 1: Move all secrets to the server side

This is the single most impactful thing you can do. Go through your codebase (or ask the AI to help you) and find every API key, token, or credential that appears in client-side code. Move them to:

• Environment variables on your hosting platform (Vercel, Netlify, Railway, etc.)
• Server-side API routes that proxy requests to external services
• Backend functions that handle sensitive operations

Your frontend should never contain a secret. Period.

Step 2: Enable database security rules

If you're using Supabase, enable RLS on every table and write policies that restrict access based on the authenticated user. If you're using Firebase, replace the default rules with specific rules for each collection.

Don't rely on the AI to get this right on the first try. Test your rules by trying to access data you shouldn't be able to.

Step 3: Add server-side authorization

Every API endpoint that modifies data or returns sensitive information needs to verify who's calling it. This means:

1. Check the session/JWT token on every request
2. Verify the user has permission for the specific action
3. Don't just check "is logged in" -- check "is this user allowed to do this specific thing"

Step 4: Add security headers

Most hosting platforms let you configure response headers. Add them. If you're on Next.js, use next.config.ts headers. On Vercel, use vercel.json. On Netlify, use _headers.

At minimum, add:

Content-Security-Policy: default-src 'self'; script-src 'self'
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

Step 5: Audit your dependencies

Run npm audit or yarn audit in your project. Update anything with known vulnerabilities. Remove packages you're not actually using. If you don't understand your dependency tree, ask the AI to explain it -- that's something it's actually good at.

Step 6: Scan your app regularly

Security isn't a one-time thing. Every time you prompt the AI to add a feature, it might introduce new vulnerabilities. You need to scan after every significant change.

This is exactly what ScanVibe does. Point it at your URL, and it checks for all the issues described in this guide -- exposed secrets, missing headers, database misconfigurations, vulnerable dependencies, and more.

Vibe Coding Security by Platform

Different AI coding platforms have different default behaviors. Here's what to watch for on each one.

Lovable

Lovable generates full-stack apps with Supabase backends. The biggest risk is disabled RLS on Supabase tables. Lovable also tends to put Supabase configuration in frontend code, which is fine for the anon key (it's meant to be public) but only if RLS is properly configured. Always verify your Supabase dashboard after deploying a Lovable app.

Bolt

Bolt runs in the browser and deploys to various platforms. It tends to embed all configuration in client-side code since it's building everything in one environment. Watch for API keys in JavaScript bundles and make sure any backend services have proper access controls.

Cursor

Cursor is the most developer-oriented tool, which means it produces code that looks professional but still has the same vibe coding security issues. Cursor might scaffold a project with proper-looking architecture but still hardcode secrets, skip RLS, or use insecure defaults. Don't let the polished output fool you into skipping a security review.

Replit

Replit's AI agent can build and deploy full apps. It uses Replit's secrets manager for environment variables, which is good. But the generated application code may still expose secrets in API responses, lack authorization checks, or use overly permissive CORS settings.

v0

v0 focuses on UI generation and usually doesn't handle backend logic directly. The main risk is in how the generated frontend components interact with external APIs. Make sure API calls go through server-side routes, not directly from the browser.

Secure Vibe Coding: Best Practices

You don't have to stop using AI coding tools. You just need to add security into your workflow. Here are the practices that make secure vibe coding possible.

1. Include security in your prompts

When you describe what you want, mention security explicitly. Instead of "add user authentication," try "add user authentication with server-side session validation, HttpOnly cookies, rate-limited login, and CSRF protection." The AI responds to what you ask for.

2. Treat the AI as a junior developer

Would you let a junior developer push code to production without a review? No. Apply the same standard to AI-generated code. Review it -- or have it reviewed -- before deploying.

3. Scan before you ship

Run a security scanner against your deployed app before sharing it with users. Catch the obvious issues before an attacker does.

4. Keep scanning after you ship

New features mean new potential vulnerabilities. Set up regular scans. ScanVibe's Pro plan includes scheduled scans that automatically check your app on a recurring basis.

5. Learn the basics

You don't need to become a security expert, but understanding the difference between client-side and server-side code, what an API key is, and why database rules matter will save you from the most common mistakes.

Conclusion

Vibe coding has democratized software development. That's a good thing. But vibe coding security hasn't kept pace with vibe coding speed. The result is thousands of live applications with critical vulnerabilities -- exposed API keys, open databases, missing authorization, and more.

The fix isn't complicated. It starts with awareness (you're reading this, so you're already ahead), continues with a systematic audit (use the checklist above), and is maintained through regular scanning.

Don't wait for a breach to take vibe coding security seriously.

Ready to find out if your app is vulnerable? Scan your app for free at scanvibe.dev. ScanVibe checks for exposed secrets, missing security headers, database misconfigurations, vulnerable dependencies, and more -- in seconds. Built specifically for apps created with Lovable, Bolt, Cursor, Replit, and other AI coding tools.