Is Vibe Coding Bad? The Security Perspective

No, vibe coding is not bad. It is one of the most exciting shifts in software development in years, putting real building power into the hands of people who never thought they could ship a product. But — and this is a meaningful "but" — vibe coding introduces security blind spots that most builders are completely unaware of. Understanding those blind spots is the difference between launching a solid app and accidentally handing your users' data to anyone who knows how to open browser DevTools.

What Is Vibe Coding?

Vibe coding is the practice of building software by describing what you want in natural language and letting an AI tool — Cursor, Lovable, Bolt, Replit, v0 — generate the code for you. You focus on the product vision and user experience. The AI handles the implementation. The term was coined by Andrej Karpathy in early 2025, and it has since exploded into a genuine movement: tens of thousands of people are shipping real apps without writing traditional code.

If you want a deeper breakdown, we wrote a complete vibe coding security guide that covers the full landscape.

The Case for Vibe Coding

Before we talk about risks, let's be clear about why vibe coding matters. Dismissing it outright would be intellectually dishonest.

Democratization of building

For decades, the ability to create software was locked behind years of computer science education or self-taught grind. Vibe coding breaks that barrier. A small business owner can build an internal tool. A designer can prototype a working app. A student with a startup idea can ship an MVP in a weekend. This is genuinely powerful and worth celebrating.

Speed

Even experienced developers use vibe coding tools to move faster. Scaffolding a full-stack app that would have taken days now takes hours. Iteration cycles shrink from weeks to afternoons. For startups racing against runway, this speed advantage is existential.

Prototyping and validation

Vibe coding is exceptional for testing ideas. Instead of spending months building something nobody wants, you can have a working prototype in front of users within days. The "build, measure, learn" loop has never been tighter.

Lower cost to start

No need to hire a development team for your first version. No need to spend $50K on an agency. A founder with a clear vision and a good AI tool can get remarkably far on their own.

These are real, substantial benefits. The question is not whether vibe coding is valuable — it clearly is. The question is what it misses.

The Security Blind Spots

Here is the uncomfortable truth: AI code generators are optimized to produce code that works, not code that is secure. They are trained to satisfy the prompt, and security requirements are almost never part of the prompt.

This is not a flaw in the tools. It is a natural consequence of how they operate. When you tell Cursor to "build a user dashboard that shows account data," it will build a user dashboard that shows account data. It will not, on its own, ask whether that dashboard checks if the logged-in user is authorized to see that specific account's data. It will not add rate limiting to prevent abuse. It will not ensure that API keys are stored in environment variables instead of hardcoded in the frontend.

Here are the most common security blind spots we see in vibe-coded applications:

1. No real authentication or broken authentication

AI tools often generate login forms that look correct but lack proper session management. Tokens stored in localStorage instead of HttpOnly cookies. No session expiration. No CSRF protection. The UI says "you are logged in," but the underlying security model is paper-thin.

2. Exposed secrets in client-side code

This is the most frequent issue we detect. API keys, database connection strings, and service credentials end up in JavaScript bundles that are visible to anyone who opens browser DevTools. The AI puts the key where it needs to be for the code to work — in the file that makes the API call — without considering that the file is shipped to the browser.

We wrote a dedicated deep-dive on exposed API keys in AI-generated apps if you want the full picture.

3. Missing server-side authorization

The app might check permissions in the UI — hiding buttons, redirecting pages — but the API endpoints behind those buttons accept requests from anyone. An attacker does not need to see your admin button to call your admin API. This is especially common in Next.js and Supabase apps where the line between client and server is blurry.

4. Default database configurations

Supabase and Firebase are the backends of choice for most vibe coders. Both are excellent services, but their default configurations are permissive by design — they are meant to help you get started quickly. Row Level Security (RLS) is disabled by default on new Supabase tables. Firebase security rules default to open access in test mode. The AI will create tables and collections without tightening these defaults, because the code works fine without them.

5. No rate limiting

Without rate limiting, a single attacker can hammer your API endpoints thousands of times per second. This can drain your usage-based billing (Supabase, OpenAI, Vercel), scrape your entire database, or brute-force user passwords. AI-generated code almost never includes rate limiting because it is not part of making things "work."

6. Missing security headers

No Content-Security-Policy. No X-Frame-Options. No Strict-Transport-Security. These headers are invisible to the user and to the AI's definition of "working," but they protect against entire classes of attacks like clickjacking, XSS, and protocol downgrade attacks.

Real Examples of What Goes Wrong

These are not hypothetical scenarios. These are patterns we see repeatedly when scanning vibe-coded applications.

API keys in JavaScript bundles

A founder builds a SaaS with Lovable, connecting it to OpenAI for AI features. The OpenAI API key is placed directly in the frontend code. Anyone can extract it, use it to make API calls on the founder's account, and run up a bill of hundreds or thousands of dollars in hours. We have seen this with OpenAI keys, Stripe secret keys, and database credentials.

// This is in your browser bundle. Everyone can see it.
const openai = new OpenAI({
  apiKey: "sk-proj-abc123..."
});

Supabase anon key used as if it were an admin key

The Supabase anon key is meant to be public — it is designed for client-side use with RLS protecting the data. But when RLS is not enabled (because the AI never turned it on), the anon key effectively becomes an admin key. Anyone with that key can read, modify, or delete any row in any table. We regularly see apps where user data, payment records, and private content are fully exposed.

No RLS on user data tables

A vibe coder builds an app where users store private notes. The AI creates the notes table, sets up the CRUD operations, and everything works perfectly — for the current user. But without RLS policies, any authenticated user can read every other user's notes by simply modifying the query. The UI only shows your own notes, but the database has no such restriction.

Authentication that only exists in the UI

The app has a login page, a registration page, and a logout button. It looks secure. But the API endpoints that serve user data do not check the session token — or check it only on the frontend before making the request. An attacker can call the API directly and access any user's data without ever logging in.

How to Vibe Code Safely

Vibe coding does not have to be risky. Here are concrete, actionable steps that any vibe coder can take, regardless of technical background.

1. Scan your app before you launch

This is the single most impactful thing you can do. A security scanner will catch exposed keys, missing headers, open database configurations, and other issues in minutes. You do not need to understand the technical details — just fix what the scanner flags.

2. Use environment variables for all secrets

Never put API keys, database passwords, or service credentials directly in your code. Every platform (Vercel, Netlify, Replit) supports environment variables. Tell your AI tool: "Use environment variables for all API keys and secrets. Never hardcode them."

3. Enable Row Level Security on every table

If you are using Supabase, enable RLS on every single table, no exceptions. Write policies that ensure users can only access their own data. Tell Cursor or Lovable: "Enable RLS on all tables and create policies so users can only read and write their own rows."

4. Add authentication checks on the server

Do not trust the frontend to enforce access control. Every API endpoint that serves or modifies user data must verify the session token on the server side. Tell your AI: "Add server-side authentication checks to every API route. Return 401 if the user is not authenticated."

5. Add rate limiting to public endpoints

Protect your scan, login, registration, and API endpoints with rate limiting. This prevents abuse and protects your billing. Upstash Redis makes this straightforward even for simple setups.

6. Prompt the AI for security explicitly

AI tools respond to what you ask for. If you never mention security, you will not get security. Add security requirements to your prompts:

• "Ensure all API routes check authentication"
• "Store all secrets in environment variables"
• "Add rate limiting to this endpoint"
• "Enable RLS and create appropriate policies"
• "Add security headers to the response"

7. Review what the AI generates

You do not need to understand every line of code, but you should look for obvious red flags: API keys in plain text, database URLs in frontend files, and endpoints that do not check who is calling them.

Conclusion: Vibe Coding + Security Awareness = Great

Vibe coding is not bad. It is a powerful new way to build software, and it is here to stay. But like any powerful tool, it requires awareness of its limitations.

The core issue is simple: AI generates code that works, but "working" and "secure" are not the same thing. Security is about what the code does not allow, and AI does not think in terms of restrictions unless you tell it to.

The good news is that the gap is easy to close. You do not need a security degree. You need a scanner, a few good habits, and the awareness that security will not happen automatically.

Vibe coding with security awareness produces apps that are fast to build, great to use, and safe for your users. Vibe coding without that awareness is a gamble with your users' data and your reputation.

Scan your vibe-coded app for free at scanvibe.dev and find out where you stand in under 60 seconds.