Vibe Coding Is Easy, Fun and Hiding a Much Bigger Security Problem

Vibe coding has changed how quickly we build software. The problem is that it can also change how quickly we create security vulnerabilities.

There is something almost magical about vibe coding. You describe what you want like “Build me a dashboard with authentication, a database, charts, payments, and an admin panel.”

A few minutes later, there is an application running in your browser.

And suddenly, you are no longer thinking like a programmer. You are thinking like a product builder. That is exactly why vibe coding is so exciting.

But there is a problem.

The easier it becomes to create software, the easier it becomes to create software that nobody has properly secured.

And this is where I think the conversation around vibe coding is missing the most important part.

We talk about:

But we don’t talk enough about what happens when the person creating the application doesn’t know what the generated code is actually doing.

Because the application can look perfect, the UI can look professional, login screen can look secure, database can contain real data or API can return JSON.

The application can pass a demo and still be completely broken from a security perspective.

The dangerous part of vibe coding isn’t that AI writes bad code.

It is that AI can write convincing code that looks correct enough that humans stop questioning it.

The term vibe coding became popular because it describes a fundamentally different way of building software.

Instead of writing:

You might simply tell an AI coding tool:

The AI figures out the implementation. Tools such as Claude Code, Cursor, Lovable, Bolt, v0 and similar systems have made this workflow increasingly powerful.

For prototypes, internal tools and even production applications, this can be incredibly productive and I’m not against it.

Quite the opposite.

Vibe coding is one of the most interesting changes to software development in years.

The problem starts when we confuse “The application works.” with “The application is secure.”

Those are two completely different statements.

Let me start with something I have personally seen. Imagine a job listing displaying Salary Not Disclosed

Looks fine and the user cannot see the salary.

But open DevTools. Go to Network → API request → Response

And suddenly:

The UI says Salary not disclosed and the API says Here is the salary.

That isn’t security, that’s UI hiding.

A similar case was publicly reported involving Naukri, where salary information was reportedly present in an API response despite the UI displaying the salary as undisclosed. The issue was subsequently fixed so that the sensitive salary values were no longer exposed to the browser.

The engineering lesson is much bigger than the specific website.

It doesn’t matter whether you:

If the sensitive value is already inside the browser’s response It isn’t secret anymore.

I have seen another version of the same problem inside Finance Product delivered to a company.

Before the official appraisal announcement, employees weren’t supposed to know their appraisal percentage.

The UI didn’t show it, everything looked normal. But someone inspected the application’s network requests.

The API response contained information related to:

The information was already being delivered to the client. The UI was simply choosing not to display it. Think about what happened here.

The frontend developer may have thought “The employee can’t see the appraisal percentage.” but the backend had effectively said “Here you go. I’m sending it anyway.”

This is one of the oldest lessons in web security Frontend code is not a trusted environment.

Anything delivered to the browser should be considered potentially accessible to the person controlling that browser.

This isn’t even specifically a vibe-coding problem. In fact, your first two examples are important precisely because they happened in conventional software systems.

And that’s the point.

Vibe coding doesn’t invent these mistakes. It can dramatically increase the number of people capable of making them.

This is where things become interesting. A traditional development team might have:

Now imagine someone building an application using an AI coding agent.

They say:

AI creates one.

AI creates one.

AI creates the database integration.

AI adds some conditional rendering.

The developer sees:

when they are an admin.

And:

when they aren’t. Looks secure. But what happens if the authorization exists only here?

That is not authorization. That is rendering logic.

A malicious user could potentially bypass the UI and call the underlying API directly.

The backend needs to enforce:

The browser should never be the final authority.

The biggest problem isn’t simply:

Humans make mistakes too. The deeper problem is scale.

Before AI:

With AI:

And now imagine the developer doesn’t deeply understand all 5,000 lines.

That’s where the risk changes.

AI doesn’t just accelerate development. It accelerates the production of both good code and bad code.

Research from Wiz found recurring security problems in vibe-coded applications, including client-side authentication, exposed API keys, overly permissive database access and sensitive applications without adequate authentication.

Veracode’s 2025 GenAI Code Security Report similarly concluded that LLM-generated code continues to introduce security vulnerabilities at concerning rates even as models become better at producing functionally correct software.

That’s the distinction developers need to understand:

An AI can produce:

while your application is leaking:

One of the easiest mistakes for AI-generated applications is putting secrets into frontend code.

For example:

Or:

The second example is particularly dangerous because NEXT_PUBLIC_ variables in Next.js are intentionally exposed to the browser.

Once bundled into frontend JavaScript, the secret isn’t a secret anymore.

A user can inspect:

And potentially find it.

Vercel has explicitly highlighted exposed secrets as a recurring problem in AI-generated applications and reported blocking large numbers of insecure deployments involving exposed credentials.

The correct architecture is:

Not:

This isn’t hypothetical.

In February 2026, The Register reported on research involving a Lovable-hosted application where a researcher claimed to have found 16 vulnerabilities, including six classified as critical, with the application exposing data associated with more than 18,000 users.

The important detail isn’t the platform, it’s the pattern.

AI makes it incredibly easy to connect:

But making those pieces work doesn’t automatically mean:

have been implemented correctly. That’s where experienced engineering still matters.

Another excellent example came from Wiz research into Base44, an AI-powered/vibe-coding platform.

Wiz discovered a vulnerability that allowed unauthorized users to access applications intended to be private.

The attack involved undocumented registration and verification endpoints that could be abused using an application’s non-secret app_id.

The result?

An attacker could bypass intended authentication controls, including SSO, and access private applications.

Wiz reported that the affected applications included enterprise use cases involving:

The issue was reportedly fixed in less than 24 hours, and the company said it found no evidence of exploitation.

This is the scary part.

The vulnerability wasn’t some Hollywood-style zero-day. It was fundamentally an authorization and authentication design problem.

And AI-powered development platforms can make these kinds of mistakes much easier to reproduce at scale.

Now let’s move from vibe-coded applications to something even more uncomfortable.

Anthropic’s Claude, A tool used by developers, engineers, researchers, companies and professionals around the world.

In July 2026, users discovered that publicly shared Claude conversations and Artifacts could appear in Google search results.

A simple search operator such as:

could surface shared conversations.

Reports described exposed material ranging from programming discussions and work notes to highly sensitive information, including medical documents, company information, personal details and, in some cases, credentials or keys.

And Artifacts were part of the story too.

Published Claude Artifacts, documents, apps and interactive creations were also discoverable through search.

Anthropic’s position was that users had deliberately created public share links, and those links were intended to be publicly accessible.

That’s an important distinction.

This wasn’t a claim that private, unshared Claude conversations were dumped from Anthropic’s database.

The issue was that content users had shared publicly could become discoverable through search engines in ways many users apparently didn’t expect.

And that’s exactly why this incident matters.

This is an important security lesson. Developers sometimes think:

That’s called security through obscurity. It can be useful as an additional layer. It should never be the security boundary.

A public URL can be:

And once it’s public you no longer control where it goes.

Anthropic’s own documentation says that shared Claude chats can be viewed by anyone with the share link.

The July 2026 incident simply demonstrated how dramatically the audience can expand when search engines discover those links. TechCrunch reported that Google results later stopped returning the affected conversations, although Artifacts had remained discoverable for a period.

Imagine a developer building an internal company application with Claude.

They paste:

Then they ask:

Except now the artifact may contain information that was never supposed to become public. The problem isn’t that AI deliberately leaked the information.

The problem is that the developer never treated the generated artifact as a potentially public web resource.

That’s a very different mindset from traditional development.

There is one sentence I increasingly worry about:

Because “it works” can hide:

The application can work perfectly and still be vulnerable.

Traditional software development had a natural bottleneck. Writing software was hard. That forced people to understand at least some of what they were building.

AI removes that bottleneck.

Now:

can happen incredibly quickly. That’s fantastic for innovation. But security reviews haven’t become 100× faster.

So we get:

This is the real danger.

We’re increasing the supply of software faster than we’re increasing the supply of people who know how to secure it.

I’m not saying “Stop vibe coding”, that would be ridiculous. Instead Vibe code aggressively but security-review deliberately. Here is the workflow I recommend.

Don’t assume:

Instead ask:

Especially around:

This should be non-negotiable.

Bad:

Bad:

Good:

Your browser is hostile territory. Treat it that way.

This is exactly where the Naukri and appraisal examples become useful.

Don’t test:

Test:

Don’t test:

Test:

The security question is always Can I access data I shouldn’t have access to?

For every sensitive feature, inspect:

Ask:

Your browser’s Network tab is one of the best security debugging tools you already have.

If you’re using Supabase, Firebase, MongoDB, PostgreSQL or another backend:

Don’t stop at “The connection works”. Ask:

Wiz found overly permissive or missing database access controls among recurring risks in vibe-coded applications.

This is one of the most useful changes you can make.

Don’t only ask:

After it is complete, ask:

Then ask:

You’re turning the AI from:

into:

It isn’t a replacement for professional security testing. But it is a huge improvement over blindly accepting generated code.

This deserves its own rule.

Don’t paste:

into an AI conversation simply because “I need help debugging this.”

Redact first.

Use:

The AI doesn’t need your real secret to explain the problem.

This applies not only to Claude.

It applies to:

Before clicking Publish ask “Would I be comfortable seeing this on Google?”

If the answer is no Don’t publish it.

I think this is going to become one of the most important developer skills of the AI era.

You don’t necessarily need to memorize every OWASP vulnerability. But you need to develop the instinct to ask Where is the trust boundary?

For example:

Where is authorization enforced?

Another:

What prevents the AI agent from performing an operation it shouldn’t?

Another:

Who can see the artifact?

These questions become more important as AI increasingly writes and executes code.

That’s the wrong debate. The more interesting question is:

Because that changes the economics of software.

One developer can build:

in dramatically less time.

But the developer also inherits responsibility for all those layers. AI can compress implementation time. It cannot compress accountability.

If your application leaks customer data, saying “Claude wrote that” isn’t going to help.

I actually think vibe coding is fantastic.

But there is a line we shouldn’t cross. The line is Using AI to write code you don’t understand and deploying it into an environment you don’t know how to secure.

That’s where productivity becomes risk.

If I had to reduce this entire article to one rule, it would be:

Here are the few things you can try:

But you should deliberately review:

Because those aren’t merely coding details. They define your application’s security boundary.

The most dangerous application isn’t necessarily the one written by a bad developer.

It might be the one that looks incredibly good.

The UI is polished, animations are smooth, authentication screen works, database is connected and deployment is live.

The AI says:

And nobody asks:

That’s the question we need to start asking. Because the future of software development isn’t going to be Humans write code.

It is increasingly going to be Humans describe systems. AI builds them.

And when that happens, the developer’s most valuable skill won’t simply be knowing how to generate code.

It will be knowing where to distrust the code.

Before shipping an AI-generated application, ask:

If the answer to the last question is no, your application probably hasn’t had a security test.

It has had a demo and those are very different things.

I hope you found it helpful and informative. If you have any questions or feedback, feel free to leave a comment below. Your support and engagement mean a lot to me.