Read this before you vibe-code another app

Bob Starr was delighted with his vibe-coded website. “Boomberg” showed how much US tax money is going to tech companies, and Starr launched it online immediately after making it. It wasn’t until months after the site went live that he realized there was a problem: a hidden SQL injection risk. It could’ve left the site open for an attacker to read or alter data they shouldn’t have access to.

Read this before you vibe-code another app

Your dream vibe-coded app might be a security nightmare.

“It was just a glaring oversight on my part. It was a complete blindspot in my state of learning this new technology and understanding it, and I’m sure there are others making the same mistake,” said Starr, a project manager in the tech sector.

“It was a complete blindspot in my state of learning this new technology and understanding it.”

Starr fixed the issue, but he isn’t alone. Across social media, there are horror stories about vibe-coded apps full of security vulnerabilities. Jer Crane, founder of PocketOS, posted on X about an AI coding agent wiping out his company’s production database. Joe Procopio, a serial entrepreneur and former developer, vibe-coded a web app to privately show demos of other apps he’d built. Hackers came, so he took the app down. “Now I do demos the old fashioned way, from my local machine over Zoom,” he wrote. “It’s sooo 2023.”

We’ve entered a new “era of personal software,” as The Verge’s David Pierce said, where anyone can use AI to create their own private apps that can do exactly what they want. But with it comes a new era of security issues. Apps may be easy to build, but they’re difficult to secure — especially in a world where AI can also be used to attack them.

“My general core take is that vibe coding is not bad because amateurs can build software. That’s actually the good part,” says Gabriel Bernadett-Shapiro, distinguished AI research scientist at AI-powered cybersecurity firm SentinelOne.

The danger, he says, is when a personal app drifts into the realm of business software and stores shared, hosted data without anybody realizing that shift has happened. And, he says, the calculus changes when vibe coding moves away from local apps for tracking migraines or meals or package deliveries and enters the realm of apps that handle customer logs, medical data, financial records, or internal documents.

“Those need to be held to a different standard. Even if it was built by one person in an afternoon. Even if the software creating the software was trivial. The moment that it touches other people’s personal data, then that’s when I think the standard changes.”

Jack Cable, CEO and cofounder of Corridor (the security platform built for AI-native software development), agrees.

“Vibe coding is not bad because amateurs can build software. That’s actually the good part.”

“Vibe coding is great for lower risk things,” Cable says, such as a prototype, or a fitness tracker that isn’t super sensitive. But financial records deserve more scrutiny, he says, as does anything on the public internet. “Are you exposing any of your own or other people’s data there?” he asked. “Think through what the threat model looks like, and if you’re not sure if something you’re doing is secure, better safe than sorry.”

That is what Max Segall, chief operating officer at the crypto wallet firm Privy, had done after he vibe-coded EzRun as a fun way of rewarding his kid with $10 in Ethereum every time the two went running together. Thankfully, a colleague found a critical flaw that would have let anyone modify user accounts to gain access — before launch.

In a more concerning and high-profile case in late January, a developer named Matt Schlicht launched a viral social network called Moltbook. It was built entirely for AI agents, and he did not write a single line of code. Within days, researchers at the security firm Wiz says it found the app’s entire production database wide open, exposing tens of thousands of email addresses and private messages. Moltbook patched the bug shortly after being told about it, but this wasn’t a one-off. Wired reported that researchers at cybersecurity firm Red Access found roughly 5,000 publicly accessible apps built with popular vibe-coding tools that had no authentication, and close to 2,000 of those appeared to be leaking sensitive data like medical and financial information, strategy documents, and even logs of chatbot conversations.

To be fair, plenty of professionally made pre-AI software is woefully insecure, too. But just as vibe coding exponentially increases the number of apps being produced, the number of security risks is also likely skyrocketing. And it adds the risk of overconfidence. When an AI tool tells you code is secure, it’s easy to believe it.

“If you’re not sure if something you’re doing is secure, better safe than sorry.”

And in a normal vibe-coding session, nothing stops to check on its own unless you’ve installed something that has, which most casual coders have not. The build just keeps going. The security tools that exist have to be invoked. While Claude Code has a /security-review command that scans for vulnerabilities, you have to ask it to do so. There’s an automatic version, but only if you set it up to run on pull requests in advance, which is something that most casual builders aren’t doing.

OpenAI’s own coding agent Codex has a built-in security agent, Codex Security, that scans commits as they land and re-scans its own proposed patches, but it’s aimed at developers with real version-control workflows, not someone chatting an app into existence. For everyone else, the takeaway is simple: You have to prompt for security up front when you build, and again at the end, especially, any time the tool has access to data you care about.

“A lot of security is contextual,” Cable says, so while it definitely doesn’t hurt to run a coding agent’s own review, he cautions against having a false sense of security from it, especially when the agent doesn’t understand your threat model, or you haven’t given it the correct guidance.

Bernadett-Shapiro says that his biggest concern is not buggy AI-generated code, but a lack of authentication, something developers may not think about when they transition an app they run locally into the cloud with a bunch of configuration options they don’t understand, leading to sensitive data being exposed. This is the failure that worries him most, and for good reason: Apps that run fine locally put on the cloud can be like leaving a box of secrets open on the sidewalk — something researchers keep finding.

AI is good at finding bugs when prompted. There have been improvements in models with things like Mythos, the same Anthropic model that set off alarm bells for how easily it finds vulnerabilities to attack, which can also be used to harden apps vibe coders are building. Bernadett-Shapiro says GPT-5.5-Cyber, or even the base models of other applications, can assess the security and identify issues in an app that even a skilled developer may have looked over. Of course, he points out that people may not understand security tradeoffs they’re making or even ignore warnings as acceptable risk.

“A lot of security is contextual.”

Some of the scaffolding is starting to exist. OWASP, the nonprofit behind many web security standards, has published an AI security verification standard aimed at organizations. Firms like Trail of Bits have started releasing “skills,” add-on instruction packs that point a coding agent at specific security tasks, like flagging insecure default settings or hardcoded passwords before they ship. Skills have to be specifically triggered, so they don’t fit very naturally into the flow of development, Cable says, and it’s hard to keep them updated and synchronized across coding agents and as the codebase changes.

Beyond that, skills can cut both ways, because malicious skills also exist.

In February, 1Password’s Jason Meller examined the mos