Vibe Coding Security Risks: What Actually Goes Wrong When AI Writes Your Backend

You built the prototype with Cursor, Lovable, Bolt, v0, or Claude Code.

It works.

Users can sign up. They can log in. The dashboard loads real data. You can click around for twenty minutes and nothing breaks.

So you start telling people it's ready.

Here's the problem. "It works when I click around" and "it's safe to put in front of strangers with real accounts and real data" are two completely different claims. AI coding tools are very good at the first one. They are not automatically good at the second one, and the gap between the two is where almost every vibe coding security story comes from.

This isn't an argument that AI-generated code is dangerous. It's an argument that AI-generated code is unreviewed code, and unreviewed code has always had this problem — AI just made it dramatically faster to produce.

When people talk about "vibe coding," they usually mean building an application mostly through natural language prompts, letting the model generate the implementation, and iterating based on what the UI does. It's a legitimate way to build software quickly. It is also a workflow that optimizes for one thing: does the feature appear to work.

An AI coding assistant will happily generate an endpoint that returns the right data for the account you're testing with. It has no independent motivation to ask "what happens if a different user requests this same endpoint with a different ID." That question requires someone to actually think about the system from an adversarial angle, and most prompts never ask for that.

This matters because the backend doesn't know or care that a human didn't write the SQL query or the auth check by hand. A missing ownership check behaves exactly the same whether a senior engineer forgot it at 2am or a model generated it in half a second. The database will still return whatever the query asks for.

So the real question isn't "did AI write this." It's "did anyone check what this code actually allows a user to do, versus what it was supposed to allow."

Authentication — proving who you are — is usually fine in AI-generated apps. Login flows, sessions, password hashing: these are common patterns the model has seen thousands of times, and they tend to be implemented reasonably well.

Authorization — proving what you're allowed to do once you're logged in — is where things fall apart. This is the difference between "is this a valid user" and "does this specific user have the right to see this specific piece of data."

Here's the pattern, almost every time:

GET /api/orders/123

The server checks:

• Is there a valid session token?
• Is the user logged in?

But it never checks:

• Does the logged-in user actually own order 123?

So a logged-in user changes the URL:

GET /api/orders/124

And now they're looking at someone else's order. Someone else's invoice. Someone else's shipping address. Depending on what the app does, maybe someone else's medical intake form or someone else's payment details.

This is called an IDOR — Insecure Direct Object Reference — and it is one of the oldest, most well-documented vulnerability classes in web development. It predates AI coding tools by decades. AI tools didn't invent this mistake. They just make it easier to ship an app with dozens of endpoints in a weekend, each one a candidate for the same missing check.

Why does this keep happening? Because "does the query return data" and "does the query return only the data this user should see" look identical in a quick manual test. You're logged in as yourself. Of course order 123 is yours. The bug is invisible until someone deliberately tries order 124, and most people building a prototype never do that, because why would they attack their own app?

This is exactly the kind of check that has to be tested independently of the UI — not by clicking around, but by directly hitting the API with a different user's session and a different resource ID.

The second recurring issue is secrets — API keys, database credentials, third-party service tokens — leaking into code that ships to the browser.

This usually isn't intentional. It happens because AI tools generate code fast, and "fast" often means grabbing an environment variable and using it wherever it's convenient, including in client-side code that gets bundled and sent to every visitor's browser.

A simple version of this mistake looks like:

// client-side component
const response = await fetch("https://api.stripe.com/v1/charges", {
  headers: {
    Authorization: `Bearer ${process.env.STRIPE_SECRET_KEY}`,
  },
});

That environment variable might be perfectly safe on a server. Bundled into a frontend build, it's now sitting in plain text in your JavaScript, visible to anyone who opens their browser's dev tools and looks at the network tab or the source files.

The fix — keeping secret keys server-side and only exposing scoped, public-safe keys to the client — is basic, well-understood practice. It's also easy to skip when you're moving fast and the app "works" either way, because the browser can't tell you it just leaked a key. It just quietly does it.

A related issue: many AI-built apps enforce all of their access rules in application code and none of them at the database level.

That sounds fine in theory — the app checks permissions, the app decides what to return — until something bypasses the app layer. A second internal tool. A background job. A direct database connection during debugging. A new endpoint someone adds later without realizing the "real" security logic lives three files away in a different part of the app.

If the database itself has no row-level permissions and will hand back any row to any authenticated connection, then your actual security boundary is "hopefully nobody wrote a query that skips the check." That's not a boundary. That's a habit, and habits break under pressure or under a deadline.

This is why production-grade systems generally enforce ownership and access rules at more than one layer — application logic and database-level constraints — rather than trusting a single checkpoint to catch everything, forever, across every future change.

When an AI tool generates a backend, it also picks packages — an auth library, an ORM, a queue, maybe an AI SDK for a feature you asked for. Most of the time these are reasonable, popular choices. Sometimes they're outdated, abandoned, or pulled in with far more permissions than the feature actually needs.

The risk here isn't exotic. It's the same supply chain risk that's existed in software for years: a dependency with a known vulnerability, a package that hasn't been updated since a security patch was released, or a library doing more than the one job you needed it for. The difference is that when you write the code yourself, you at least see every npm install you run. When a tool is generating and wiring code for you across dozens of files, it's easy to end up with a dependency tree nobody on your team has actually looked at.

None of this means "don't trust AI-selected dependencies." It means someone should read the list before launch, the same way you'd review a subcontractor's material list before signing off on a build.

There's a version of this problem that has nothing to do with security in the traditional sense and everything to do with what happens when your app stops being tested by one person clicking around and starts being used by actual customers at the same time.

A prototype gets built and tested by one person: you. One request at a time, one browser tab, one dataset that grows by a handful of rows a day. Under those conditions, almost any architecture "works." A single database query that scans an entire table is instant when the table has forty rows. An API call to a third-party service with no timeout or retry logic is fine when it succeeds every single time you happen to test it.

None of that tells you what happens with fifty concurrent users, a slow third-party API, or a database table that's grown past a few thousand rows.

Common patterns that surface here:

• A background job that processes records one at a time with no queue, so a spike in signups quietly stacks up a backlog nobody notices until support tickets start arriving
• A third-party API call (payment processor, email service, an AI model endpoint) with no timeout, so one slow external service hangs the entire request instead of failing gracefully
• No rate limiting on expensive or sensitive endpoints, so a single misbehaving client — or a scripted attacker — can hammer login, password reset, or checkout as fast as the server allows
• Error messages that leak internal details ("relation orders_backup does not exist") instead of a generic failure the user can act on

None of these show up in a demo. They show up during a launch, a marketing push, or a slow Tuesday when a vendor's API happens to have an outage. This is also why "the app loads" is a poor substitute for actually understanding how the system behaves when a piece of it fails or when load doesn't match your testing conditions.

The fastest way to see the gap is to put the two side by side.

Every item on the left can be true while every item on the right is false. That's not a hypothetical edge case — it's the default state of most AI-generated backends the first time someone actually looks closely, because nothing in the "does it work" feedback loop ever tests the right column.

If you're deciding whether a prototype is ready for real users, these are the checks worth doing before anything else:

• Authentication is tested (login, logout, session expiry)
• Authorization is tested independently of the UI — not just "can I log in," but "can user A retrieve user B's data by changing an ID"
• Secrets are not exposed to frontend code or visible in browser dev tools
• Database permissions match the application's access rules, not just the app's intentions
• Dependencies have been reviewed for known vulnerabilities and unnecessary permissions
• Error handling has been checked — what does the app show a user when something fails, and does it leak internal details
• Rate limiting exists on endpoints that touch sensitive actions (login, password reset, payments)

You don't need all of these to be perfect. You need to know which ones are true, which ones aren't, and what the actual risk is of shipping with the gaps you have.

None of this is an argument against building with AI coding tools. They're genuinely good at what they do: turning a clear idea into working software far faster than writing every line by hand. A founder with no engineering team can now get a real, functional product in front of early users in days instead of months. That's a legitimate advantage, not a shortcut to be ashamed of.

What AI tools don't do is replace the judgment call of "is this specific thing safe to expose to the public internet." That call still requires someone to look at the system the way an attacker would — not because attackers are lurking around every prototype, but because the only way to know your authorization logic actually works is to try to break it on purpose.

The mistake isn't building with AI. The mistake is treating "it works in my testing" as equivalent to "it's ready for production," when those have never been the same claim — for AI-generated code or hand-written code.

If you have an AI-built prototype that works but you're not sure whether the backend, data model, dependencies, or architecture are actually ready for real users, Meerako's Production Readiness Audit is a fixed-price, 3–5 day review that covers authentication, data integrity, dependency risk, and architecture under load, and ends with a written, ranked findings report you can act on with or without us.