アプリを「バイブコーディング」する前に読むべきこと

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.

“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 most downloaded skill on a popular OpenClaw skill registry and found that it directed users to install a dependency that ended up being malicious itself. It’s still the Wild West out there and can be difficult to tell whether a skill will harden your app or hand an attacker your credentials.

The potential of insecure vibe-coded apps isn’t a problem limited to hobbyists. Cable says engineers and even sales and marketing teams at big companies are now shipping far more agent-written code than before. Security teams need baseline visibility into how the agents are being used, he says, as well as guardrails that get enforced — either through skills or through products like the one Corridor sells, which aim to stop flaws before the code is even written.

For individuals, Cable’s guidelines are much simpler: Be aware that a model running locally on your own computer is far less risky than one made public, especially if it contains sensitive data.

“Literally overnight, the way most companies produce software has changed completely,” Cable says. He’s not especially worried about the coding agents themselves as long as they’re given the right guardrails in which to operate. The models themselves are increasingly built on a memory-safe stack that eliminates entire classes of vulnerabilities to begin with. “I do think there is reason to be optimistic here,” he says.

Government affairs specialist Jeff Rothblum vibe-coded an app for tackling mountains of tedious data entry with security in mind. He thought about what information the app holds, how sensitive it is, and what could happen if it got out. It’s a striking approach because it is so rare, and because the ground beneath us is shifting so quickly.

While working as head of government affairs and strategy at Lilt, he had to submit input forms to various government committees to get ideas into appropriations bills. No two forms are alike, so lobbyists may submit dozens or even hundreds of unique ones in a six-week period. After eight 75-hour weeks, and a layoff, he built a tool in case he ever had to do this again. It’s an app that scrapes links and due dates into a single dashboard and uses an LLM to prepopulate each form, so users only need to review and edit it (and paste in an account number) before submitting.

Vibe-code the app of your dreams, but think through what data the app is storing and has access to and what could go wrong.

He was well aware of the risk because he didn’t write his own code. “The last time I wrote code was probably in undergrad in 2006 writing Fortran to analyze fluid flows as an aerospace engineer,” Rothblum told *The Verge*. The biggest risk is that companies could inadvertently leak strategies or sensitive lobbying rationale, which stay private even when the filings are public. He’s mitigating this risk by running regular security reviews in Claude, keeping user data local rather than on his servers and building toward stricter retention safeguards.

He has vibe-coded his app to clear the browser and is upfront about the page sending data to Claude, linking to its retention policy. He’s working on a version of the app in which nothing a user types is stored by AI, even briefly, and a separate version that would let users route everything through their own LLM rather than his Claude instance.

While Rothblum has thought of building a broader lobbying intelligence tool, he says that if he does start working with more sensitive data, he intends to shell out four to five figures to pay an actual security engineer to review his code.”I’m happy with open-source stuff and I’m happy with ephemeral stuff, but everything else kind of scares me,” he says.

It is ideal to have a human expert review code, but Cable says that’s becoming a bottleneck. The open question, he says, is what the world looks like when most code ships without any human reading it and how we secure that world.

For now, the answer for the rest of us is smaller and more within reach: Vibe-code the app of your dreams, but think through what data the app is storing and has access to and what could go wrong. Ask it to build it with security in mind, and run code reviews after each change, including the patches the AI writes itself. Pay extra close attention before you move it from your own device into the cloud or give it access to any sensitive data or accounts. The difference between a fun project and a horror story starts with knowing what questions to ask.

7 Comments

Follow topics and authors from this story to see more like this in your personalized homepage feed and to receive email updates.

• Yael Grauer

-

-