Essential Tips for Vibe-Coding Your Next App

Bob Starr was thrilled with his vibe-coded website. “Boomberg” illustrated how much US tax money flows to tech companies, and he launched it online right after finishing it. However, months later, he discovered a significant issue: a hidden SQL injection vulnerability that could have allowed an attacker to access or modify data improperly.

“It was a glaring oversight on my part. I completely missed it while learning this new technology, and I’m sure others are making the same mistake,” said Starr, a project manager in the tech industry.

He resolved the issue, but he’s not alone in facing such challenges. Social media is filled with cautionary tales about vibe-coded apps riddled with security flaws. Jer Crane, founder of PocketOS, shared on X about an AI coding agent that wiped out his company’s production database. Joe Procopio, a serial entrepreneur and former developer, vibe-coded a web app to privately showcase demos of his other projects. When hackers targeted it, he took the app down. “Now I do demos the old-fashioned way, from my local machine over Zoom,” he noted. “It’s sooo 2023.”

We’ve entered a new “era of personal software,” as one expert put it, where anyone can leverage AI to create custom apps tailored to their needs. However, this also brings a wave of security challenges. While building apps may be straightforward, securing them is a different story—especially in a landscape where AI can also be weaponized against them.

“My main takeaway is that vibe coding isn’t bad because it allows amateurs to create software. That’s actually a positive aspect,” says Gabriel Bernadett-Shapiro, an AI research scientist at a cybersecurity firm.

The real danger arises when a personal app transitions into business software, inadvertently storing shared data without anyone realizing it. The stakes are higher when vibe coding shifts from local apps for tracking personal activities to those managing customer logs, medical records, financial data, or internal documents.

“Those need to meet a different standard. Even if built by one person in an afternoon, once it involves other people’s personal data, the expectations change,” he emphasizes.

Jack Cable, CEO and cofounder of a security platform for AI-native software development, concurs.

“Vibe coding is great for low-risk projects,” Cable explains, like prototypes or fitness trackers that don’t handle sensitive information. However, financial records require more scrutiny, as does anything exposed on the public internet. “Are you putting your own or others’ data at risk?” he asks. “Consider the threat model, and if you’re unsure about the security of your project, it’s better to be cautious.”

Max Segall, COO at a crypto wallet firm, took similar precautions after vibe-coding EzRun, a fun app that rewarded his child with $10 in Ethereum for running together. Fortunately, a colleague discovered a critical flaw that could have allowed anyone to modify user accounts before the app launched.

In a more alarming case, developer Matt Schlicht launched a viral social network called Moltbook, designed entirely for AI agents, without writing any code himself. Within days, security researchers found the app’s entire production database exposed, compromising tens of thousands of email addresses and private messages. Moltbook quickly patched the vulnerability, but this incident was not isolated. Reports indicated that researchers discovered around 5,000 publicly accessible apps created with popular vibe-coding tools lacking authentication, with nearly 2,000 leaking sensitive data like medical and financial information.

While many professionally developed pre-AI applications are also insecure, the rise of vibe coding significantly increases the number of apps being created, which likely escalates security risks. This trend can foster overconfidence; when an AI tool claims code is secure, it’s easy to take that at face value.

During a typical vibe-coding session, there’s often no automatic check unless specific security tools are installed, which most casual coders don’t have. The build process continues without interruption. Existing security tools must be manually invoked. While some coding agents offer commands to scan for vulnerabilities, users must request these checks. Automatic scans can be set up, but most casual builders don’t configure them in advance.

OpenAI’s coding agent includes a built-in security feature that scans commits and proposed patches, but it’s designed for developers with established version-control workflows, not for those casually creating apps. The key takeaway is clear: prioritize security from the start and again at the end, especially when handling sensitive data.

“A lot of security is contextual,” Cable notes. While it’s beneficial to run a coding agent’s review, he warns against developing a false sense of security, particularly if the agent lacks an understanding of your specific threat model or if you haven’t provided adequate guidance.

Bernadett-Shapiro’s primary concern isn’t buggy AI-generated code but rather the absence of authentication. Developers may overlook this when transitioning an app from local use to the cloud, leading to potential data exposure. This oversight is particularly troubling, as apps that function well locally can become vulnerable when deployed online—akin to leaving a box of secrets open on the sidewalk.

AI can effectively identify bugs when prompted. Recent advancements in models, like Mythos, have shown promise in both detecting vulnerabilities and strengthening apps created by vibe coders. Bernadett-Shapiro mentions that models like GPT-5.5-Cyber can evaluate security and pinpoint issues that even experienced developers might miss. However, he cautions that users may not fully grasp the security trade-offs they’re making or may dismiss warnings as acceptable risks.

Some foundational tools are beginning to emerge. Organizations like OWASP have published AI security verification standards, and firms are releasing “skills” that guide coding agents in specific security tasks, such as flagging insecure default settings. However, these skills require explicit activation, making them less integrated into the development process, and keeping them updated can be challenging.

Moreover, malicious skills also pose a risk. In February, a security expert discovered that a popular skill directed users to install a dependency that turned out to be harmful. The landscape remains unpredictable, making it difficult to discern whether a skill will enhance your app’s security or compromise it.

The issue of insecure vibe-coded apps isn’t confined to hobbyists. Cable points out that engineers and even sales and marketing teams at larger companies are increasingly deploying agent-written code. Security teams need visibility into how these agents are utilized and enforce guardrails, whether through skills or products designed to catch flaws before code is written.

For individuals, the advice is straightforward: be mindful that a model running locally on your device is generally less risky than one made public, especially if it handles sensitive data.

“Overnight, the way most companies develop software has transformed completely,” Cable observes. He’s not overly concerned about the coding agents themselves, provided they operate within appropriate guardrails. The models are increasingly built on a memory-safe stack, reducing entire classes of vulnerabilities from the outset. “I believe there’s reason for optimism,” he adds.

Jeff Rothblum, a government affairs specialist, vibe-coded an app to streamline tedious data entry with security in mind. He carefully considered the sensitivity of the information the app would handle and the potential consequences of a data breach. This thoughtful approach is rare, especially given the rapid changes in the landscape.

While leading government affairs and strategy at a company, he had to submit various input forms to government committees for appropriations bills. Since no two forms are identical, lobbyists may need to submit dozens or even hundreds of unique forms in a short period. After a challenging eight weeks and a layoff, he created a tool to simplify this process. The app consolidates links and deadlines into a single dashboard and uses an LLM to prepopulate forms, requiring users only to review and edit before submission.

Rothblum was acutely aware of the risks since he didn’t write the code himself. “The last time I wrote code was probably in undergrad in 2006,” he shared. The primary risk lies in inadvertently leaking strategies or sensitive lobbying information, which should remain confidential even when filings are public. He mitigates this risk by conducting regular security reviews, keeping user data local, and implementing stricter retention policies.

He has designed his app to clear the browser and is transparent about data sent to the LLM, linking to its retention policy. He’s also developing a version that doesn’t store any user input, even temporarily, and another that allows users to route everything through their own LLM instead of his.

While Rothblum has considered creating a broader lobbying intelligence tool, he plans to invest significantly in hiring a security engineer to review his code if he works with more sensitive data. “I’m comfortable with open-source and ephemeral solutions, but everything else makes me uneasy,” he admits.

While having a human expert review code is ideal, Cable notes that this is becoming a bottleneck. The pressing question is what the future holds when most code is deployed without human oversight and how to secure that environment.

For now, the guidance for everyone else is clear: vibe-code the app of your dreams, but carefully consider what data it stores and accesses, and what could potentially go wrong. Ensure security is a priority during development and conduct code reviews after each change, including those made by AI. Be especially vigilant before moving your app from a local environment to the cloud or granting it access to sensitive data. Understanding the right questions to ask can mean the difference between a fun project and a security nightmare.