The Hidden Danger of Vibe Coding - When Fast Code Opens Real Data Leaks

AI coding assistants are amazing. They can generate controllers, database schemas, APIs, authentication flows, landing pages and dashboards in minutes. What used to take a weekend can now appear on your screen before your coffee gets cold.

That is the promise of vibe coding: describe what you want, let the AI build it, test the happy path, deploy it, move on.

But this new speed comes with a serious downside. Code that looks finished is not necessarily safe. A button can work, a login screen can look professional, a dashboard can load real records — and behind the scenes, the database may still be wide open.

That is the real danger of vibe coding: not that AI writes bad code, but that people ship code they do not understand.

The App Works. That Does Not Mean It Is Secure.

One of the biggest traps in AI-assisted development is the difference between visible functionality and invisible security.

A generated application can look complete. The signup works. The login works. The user table exists. The frontend displays the correct data. The deployment succeeds.

From the outside, everything feels done.

But security usually fails in the parts you do not see immediately:

• Can User A access User B’s data?
• Are database rows protected by proper authorization rules?
• Are API keys exposed in the browser?
• Are admin functions reachable by normal users?
• Is sensitive data stored unnecessarily?
• Are uploads checked and isolated?
• Are logs accidentally storing personal data?
• Are development settings still active in production?

A beginner may test whether the feature works. An experienced developer also tests how it breaks.

That distinction matters.

A recent ZEIT investigation reported that hundreds of AI-built websites were misconfigured and described cases where customer data, including names, addresses, payment-related data and chats, was exposed online. The article specifically points to the risk of AI-generated websites using backend services without correct security configuration.  

Vibe Coding Often Skips the Threat Model

The problem is not the use of AI. The problem is using AI without knowing what questions to ask.

A coding agent is usually very good at implementing instructions. But if your prompt is:

Build me a small SaaS app with login, payments and a dashboard.

…the agent may create something that appears to satisfy that request. It might set up tables, generate CRUD routes, connect a frontend, and make everything feel alive.

But unless you explicitly ask for secure authorization, row-level restrictions, least-privilege permissions, input validation, audit logging and safe secret handling, you may not get them — or you may get something that looks secure but is not.

AI can produce code. It cannot automatically take responsibility for your data model, your legal obligations, your users’ trust or your production infrastructure.

That responsibility remains yours.

Authentication Is Not Authorization

This is one of the most dangerous misunderstandings in beginner-built applications.

Authentication answers the question:

Who are you?

Authorization answers the question:

What are you allowed to access?

Many vibe-coded apps stop after authentication. They check whether someone is logged in, but they do not properly check whether that person is allowed to access a specific record.

That is how data leaks happen.

For example, imagine a route like this:

/orders/123

A logged-in user should only see this order if it belongs to them. But if the backend only checks whether the user is logged in, then changing the URL to:

/orders/124

might expose another customer’s order.

This class of problem is known as broken access control. It is not a theoretical issue. OWASP ranks Broken Access Control as the number one category in the OWASP Top 10 for web application security risks, and OWASP’s 2021 data notes that 94% of tested applications showed some form of access control weakness.  

In other words: even professional teams struggle with this. Beginners who blindly trust generated code are taking a much bigger risk.

The Supabase Example: Powerful, But Not Magic

Services like Supabase are fantastic. They make it incredibly easy to build real applications quickly. You get a Postgres database, authentication, APIs, storage and realtime features without building everything from scratch.

But easy does not mean automatic security.

Supabase itself documents that exposed tables should be protected with Row Level Security and that roles should only receive the privileges they actually need.   Row Level Security is the layer that decides which rows a user is allowed to read, create, update or delete.  

This matters because many modern frontend applications talk directly to backend APIs. A key that exists in the browser should not be treated like a private server secret. The protection must come from correctly designed permissions and policies.

A common mistake is thinking:

The user cannot see that button, so they cannot perform that action.

That is wrong.

Attackers do not need your button. They can call the API directly.

Security must live on the server and database level, not only in the user interface.

The AI Will Not Feel the Risk

When a human developer writes insecure code, at least there is a chance they feel uneasy. They may pause and think: “This endpoint needs a policy.” Or: “This table contains personal data.” Or: “This should not be public.”

An AI agent does not feel that.

It will confidently generate code that looks clean. It may use modern libraries, nice naming conventions and good formatting. It may even add comments that sound reassuring.

But clean code can still be insecure code.

This is especially dangerous because AI-generated code often gives beginners a false sense of professionalism. The project looks like something an experienced developer would write. The folder structure is neat. The components are reusable. The UI is polished.

But software architecture is not only about structure. It is also about boundaries, assumptions, failure modes and abuse cases.

Data Leaks Are Not Just Technical Bugs

When personal data leaks, the problem is no longer just technical.

It becomes a trust problem, a legal problem and often a financial problem.

Under the GDPR, a personal data breach may need to be reported to the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of it, unless the breach is unlikely to result in a risk to people’s rights and freedoms.  

For a small business, startup, club, association or side project, that can be devastating.

You may have to:

• investigate what happened,
• document the breach,
• inform authorities,
• notify affected users,
• rotate credentials,
• rebuild parts of the system,
• hire external help,
• deal with reputation damage,
• pause your product launch,
• answer uncomfortable questions from customers or investors.

The irony is painful: vibe coding is often used to move faster, but one security incident can cost far more time than doing the basics properly from the beginning.

What You Should Understand Before Shipping

You do not need to be a full-time security engineer to use AI coding tools responsibly.

But before you deploy an application that stores real user data, you should understand at least the basics:

1. What data do you store?
Do you really need names, addresses, messages, files, payment metadata or health-related information? Less stored data means less risk.

2. Who can access each record?
Every table should have a clear access model. “Logged in” is not enough.

3. Where is authorization enforced?
Frontend checks are useful for user experience, but real protection must happen on the backend, database or policy level.

4. Are secrets actually secret?
Anything shipped to the browser must be considered public. Private API keys belong on the server.

5. Are database policies tested?
Test as an anonymous user, as a normal user, as another user and as an admin. Try to access records you should not see.

6. Is production configured differently from development?
Debug modes, open CORS rules, permissive storage buckets and test credentials do not belong in production.

7. Can you explain the system without the AI?
If you cannot explain how authentication, authorization and data access work, you are not ready to ship sensitive data.

Use AI Like a Junior Developer

A good mental model is this:

Do not treat an AI coding agent like a senior architect. Treat it like a very fast junior developer.

It can write a lot of code quickly. It can follow patterns. It can generate tests. It can refactor. It can help you explore ideas.

But it still needs supervision.

You define the architecture. You define the constraints. You review the output. You check the security assumptions. You decide what is safe enough to publish.

The more powerful coding agents become, the more important human judgment becomes.

Vibe Coding Is Great for Prototypes

There is nothing wrong with vibe coding a prototype.

Use it to test an idea. Build a landing page. Mock a dashboard. Create an internal tool. Explore an API. Generate boilerplate. Learn a new stack.

But the moment real user data enters the system, the rules change.

A prototype can be playful. A production system must be accountable.

The dangerous part is not vibe coding itself. The dangerous part is vibe shipping — deploying something to the public internet without understanding what the AI created.

My Rule of Thumb

Before shipping an AI-generated application, ask yourself:

Could I safely explain to a user where their data is stored, who can access it, and why another user cannot see it?

If the answer is no, do not ship yet.

Use AI to move faster, but do not outsource your responsibility. Security is not a prompt you add at the end. It is part of the architecture from the beginning.

Vibe coding can be a superpower.

But only if you know where the sharp edges are.