Vibe Coding Security: Best Practices for Secure Vibe-Coded Apps 

Everyone is vibe coding right now, but not everyone has security in mind while they’re in the zone.

Only one in every five Lovable users has a technical role. The majority of users of one of the most popular vibe coding platforms are founders, marketers, freelancers, product managers, and people with other roles that don’t necessarily have a background in software development or security. 

It’s unsurprising that vibe-coded applications can be very vulnerable to cyber attacks. In their State of Security of Vibe Coded Apps report, Escape.tech found more than 2,000 critical vulnerabilities and over 400 exposed secrets across 1,400 vibe-coded applications. 

This guide walks through why vibe-coded apps end up vulnerable, the risks they pose, and what you can actually do about it since vibe coding isn’t going away.

Why Vibe Coding Creates a Security Gap

Vibe coding, by itself, doesn’t weaken application security. Yes, LLMs make plenty of architectural mistakes, but so do humans. It’s the absence of code review, testing, and other security processes that creates the issues. Why are they missing? Here are a few common reasons.

Nobody on the Team Actually Knows the Code

In the traditional development setting, there’s at least one person on the team who wrote the code and understands why and how it works. That’s often not the case with vibe coded apps, since 63% of vibe coders in 2025 are non-developers, and this will likely increase in the coming years.

Anyone with a great idea could just describe the application or features they want in a prompt, the AI writes the code, and it runs without anyone understanding how it actually works. 

There may be problems in that code, but there’s no one there to notice them. They become evident only when something breaks or, worse, gets exploited. Without a person who understands the logic, there’s no one to flag that an authentication check shouldn’t be optional or that a query is vulnerable to code injection.

There’s No DevSecOps in the Loop

DevSecOps is the practice of folding security into every stage of the product development and deployment, instead of adding it at the end. Most vibe-coded applications don’t have this important aspect mainly because there is no DevSecOps engineer. There’s no one reviewing pull requests for security vulnerabilities, no scanner in the pipeline, no policy for what happens before the code goes live. 

The Pace of Iteration Outruns the Pace of Review

A part of the appeal of AI-assisted development in general and vibe-coding in particular is that it’s fast. A working application can be generated in one day. A revision or feature addition that used to take days to accomplish can now be done within an hour. 

The problem is that deployment speed and review don’t usually go hand in hand. Google’s DORA research team, which ran a qualitative study across 1,110 engineers, found that higher AI adoption is associated with an increase in both delivery speed and delivery instability. Because of that, engineers say that the time saved writing code is often spent later auditing it instead. 

This is fine when there is someone who actually does a thorough audit every time. But more often than not, AI-written code doesn’t get nearly enough scrutiny, especially with the push to ship faster.

Abandoned Projects Pile Up, Adding Vulnerabilities

Vibe coding makes it so easy to develop projects. Weekend experiments and half-finished MVPs get deployed, and some of them are abandoned and forgotten. Some stay online without updates and end up working on old, vulnerable technologies, while others are taken offline but leave behind dangling DNS records that an attacker can exploit. 

This adds to the organization’s already growing attack surface. In fact, cybersecurity firm RedAccess found more than 380,000 publicly accessible assets on vibe-coding platforms. About 5,000 of those were built for corporate purposes, and 40% of that corporate subset exposed sensitive information.

Risks Posed by Vibe Coding

We grouped the vibe coding risks into six categories, ranging from code-level mistakes to process failures.

Exposed Secrets

An exposed secret is any credential, API key, token, or password that ends up somewhere it shouldn’t, such as a public GitHub repo or client-side code. This is one of the most common and most preventable vibe coding mistakes. 

Hard-coded secrets are easy to miss during rapid iterations. AI models will paste an API key straight into a file if not told otherwise, and once that file is committed to a public repository, the key is out.

Mapped CWEs: This risk maps to two well-documented weaknesses in MITRE’s Common Weakness Enumeration list: CWE-798 (Use of Hard-coded Credentials) for the credentials themselves and CWE-540 (Inclusion of Sensitive Information in Source Code) for how it ends up exposed. We have a detailed breakdown of how source code disclosure vulnerabilities play out in practice.

Bad Database Rules

Row Level Security, or RLS, is a database feature that restricts which rows a user can see or edit based on who they are. AI knows what RLS is and knows it should be used, but doesn’t apply it consistently across every table and query. 

A common failure in vibe-coded apps is this: RLS is technically on, but the policy is written loosely enough that changing a user ID in a request reveals someone else’s data anyway. This isn’t a hypothetical failure mode. In March 2025, security researcher Matt Palmer found exactly this while testing Linkable, a Lovable-built app for generating sites from LinkedIn data. Missing RLS allowed anyone access to the project’s user table. His follow-up scan of Lovable’s own showcase found 303 exposed endpoints across 170 projects, all from the same root cause, later cataloged as CVE-2025-48757. 

Mapped CWE: This pattern can be mapped to CWE-639 (Authorization Bypass Through User-Controlled Key), sometimes called Insecure Direct Object Reference (IDOR).

Broken Access Control From Client-Side Checks

This is one of the more dangerous risks because the application looks secure during normal use. The AI builds a login screen and hides admin buttons and options from regular users. But all of that logic lives in the browser, which means the button is hidden from view but the underlying page or API endpoint is still reachable if you know the URL. Everyone, using developer tools built into browsers, can inspect the page, remove the restriction, and call the same backend endpoint directly, since nothing on the server checked whether the request was allowed. 

Mapped CWE: MITRE classifies this pattern as CWE-602 (Client-Side Enforcement of Server-Side Security).

Vulnerable and Unverified Dependencies

AI coding tools pull in open-source packages automatically to get a feature working fast, and most vibe coders don’t check what version was actually used in their project or whether it has vulnerabilities.

It’s also worth checking whether the library exists at all since AI can hallucinate package names that actually don’t exist yet, which an attacker can register and fill with malicious code. The next time an AI hallucinates that same name, it pulls in the attacker’s code. 

Mapped CWE: This risk can be tracked under CWE-1104 (Use of Unmaintained Third-Party Components), and Attaxion’s rundown of common network vulnerabilities covers how attackers actually find and exploit outdated software in the wild.

Over-Trust in AI Output

One of the most dangerous vibe coding security risks is the immediate acceptance of AI-generated code, no questions asked. When a feature works on the first try, many people would just move straight to the next prompt without checking if it’s safe. 

But it’s worth noting that running code is not the same thing as secure code. And when this isn’t checked thoroughly, security issues cascade into production without anyone catching them. 

This risk compounds with everything else on this list, since a team that trusts AI output by default is also the team least likely to notice an exposed secret, a missing access check, or a dependency with a known CVE or CWE, because nobody was looking for any of it in the first place.

LLM-Specific Risks (OWASP GenAI Top 10)

If a vibe-coded app has an LLM built into it (a chatbot, an AI feature, or anything that calls a model at runtime), it carries a different set of risks than a regular web app. The OWASP GenAI Security Project maintains a Top 10 list for these, including prompt injection, sensitive information disclosure, software supply chain risks, data and model poisoning, improper output handling, excessive agency, and system prompt leakage, among others. 

Note that the list covers apps that use LLMs as a runtime component, not all applications that happened to be built by vibe coding. 

Vibe Coding Security Best Practices

1. Use an AI Code Reviewer in the Workflow

This is probably the practice that can catch the most security issues with the least amount of effort. Tools like CodeRabbit plug into an IDE (VSCode, Cursor, and Windsurf) and review the code as it’s written, combining static analysis with an LLM layer to catch security issues and bad patterns before a pull request is ever opened. It also works directly on merge reviews if you’re on GitHub or GitLab, and can hand off fixes to your agentic AI coding tool so you’re not patching everything manually. 

Running a second AI to check the work of another AI may sound strange at first, but remember that the model writing your code is optimized to make things work, not to make them safe. But if adding another AI tool isn’t practical for your team yet, you can still use the same LLM you’re using for vibe coding and make a code reviewer agent out of it to catch common vulnerabilities like SQL injection and cross-site scripting.

You may also want to pair your AI code reviewer with behavioral testing, where you or an agentic AI run the feature and see what happens when you feed it inputs it wasn’t designed for.

2. Use Encryption — Both at Rest and in Transit

Data in transit should run over HTTPS, no exceptions, with HTTP traffic redirected automatically. Pentesters who intercept unencrypted traffic routinely find session tokens, passwords, and API keys exposed in plain text. There’s no longer any excuse to skip this since free certificates are available through Let’s Encrypt and other providers.

Data at rest, especially passwords, personal information, or payment details, should be encrypted too. Most managed providers (such as Supabase and PlanetScale) handle this by default across their cloud environments, but it’s always safer to confirm this rather than assume. Additionally, passwords should never be stored in plain text, and a proper hashing library should handle that. 

You should instruct your AI model on all these requirements explicitly when it’s building your application. 

3. Only Collect and Store the Necessary Data

The simplest way to avoid a data breach is to not have the data in the first place. Before asking an AI to build a signup form that captures name, email, phone number, birthday, and address, it’s worth asking whether all of that is actually necessary. 

Every field collected is a field that has to be secured, stored, and eventually explained to a regulator if something goes wrong. Minimal data collection isn’t just good privacy practice; it also helps reduce risks.

4. Keep Secrets Out of Version Control

This is probably one of the most common and most avoidable mistakes in vibe coding. A .env or .env.local file holds API keys as environment variables, and it should never be committed to version control. Set up .gitignore before the first commit, not after, since once a secret hits git history, it’s there permanently even after deletion in a later commit. 

If an AI tool pastes a key directly into source code instead of an environment variable, that needs to be detected and addressed immediately. 

We’re not talking about a theoretical risk, but a real one that had existed even before AI-assisted development became rampant. In 2020, for instance, security researchers ran a honeypot experiment where they published dummy AWS credentials in public GitHub repos and watched what happened next. It took attackers merely one minute to find the exposed key and start using it, and under one hour for most of the resulting API calls to come in, all aimed at spinning up the largest, most expensive server instances possible before anyone noticed. 

5. Validate Everything, Everywhere

Every input a user can type, upload, or submit should be treated as an attempt to break the app, because there’s always the possibility that it will be. That’s why input validation has to happen on the backend, on the server, not just in the browser. 

Frontend checks (like a form refusing to submit until a field looks right) only run on the user’s own machine, so they’re just for a smoother experience. They don’t offer real protection since anyone can open their browser’s dev tools, skip the form entirely, and send a request straight to the server with whatever data they want, effectively bypassing every frontend check in the process. 

This is one of the things pentesters like to test. They inject malicious code through form fields, URL parameters, and file uploads, from classic SQL injection to script injection, and most apps fail on the first try because the real check was never enforced on the server. The AI needs to be told explicitly to validate server-side, since it will default to frontend-only validation otherwise.

6. Verify Libraries Instead of Avoiding Them

There’s a temptation to limit development to a small list of already-trusted libraries, but that’s not really where the risk sits. A popular, actively maintained library, say one that handles password hashing, has already had that problem solved correctly, tested by thousands of other projects over years, with bugs found and patched along the way. Avoiding it doesn’t remove that problem. It just means writing a replacement from scratch, usually a rushed one built by an AI to satisfy a single prompt, with no real-world testing behind it and no one else around to catch its flaws. 

The real risk is AI-hallucinated packages, which are dependencies the AI model invents that don’t exist yet, which an attacker can then register and fill with malicious code. This is called slopsquatting, and it’s already happened in the wild. A security researcher tested the theory by uploading a harmless package under a name AI models kept hallucinating, and it picked up over 30,000 downloads in three months, including one from Alibaba’s own public GitHub repo.

So before AI auto-installs anything, the package name needs to be verified against npm or PyPI, along with a check for an up-to-date maintenance history since outdated packages carry known vulnerabilities and are usually the first thing a pentester (and an attacker) checks.

7. Add Rate Limiting and CAPTCHA

These tactics are usually overlooked because they may not feel like real security work. However, they stop most of the junk that hits a new app in its first few weeks of release. 

Without rate limiting, a bot can throw thousands of fake registrations at a signup form in minutes, filling the database with garbage and running up hosting costs. A good starting point is around 100 requests per hour per IP on sensitive endpoints like login and signup, which can be loosened later only if real users complain. CAPTCHA solves a related problem as it keeps bots from reaching forms at all. 

8. Monitor the App After Deployment

Vibe-coded apps get abandoned constantly, and abandoned apps with real data and real credentials sitting on the open internet are exactly what attackers look for. This is where continuous monitoring matters, and it’s not something most vibe coders think to set up.

A tool like Attaxion handles this by continuously scanning the external attack surface, meaning every domain, subdomain, IP, and cloud asset connected to a project. It discovers assets that may have been forgotten entirely, flags misconfigurations that could expose secrets, and scores vulnerabilities by how likely they are to actually get exploited, using CVSS, EPSS, and CISA KEV data. 

Conclusion

Vibe coding makes it possible to build and ship applications faster than ever, but that very speed creates security issues. The biggest risks usually come from skipped review steps, exposed secrets, weak access controls, unvalidated input, vulnerable dependencies, and applications that remain online long after anyone is actively maintaining them.

The good news is that vibe coding is not inherently unsecure, and improving vibe-coding security does not require turning every project into a traditional enterprise development process. A few consistent practices can make a significant difference: review AI-generated code, keep credentials out of version control, validate inputs on the server, verify dependencies, encrypt sensitive data, add basic abuse protections, and continue monitoring the application after deployment with an application security tool such as Attaxion.

AI can generate working code in seconds. If you treat security as part of the vibe-coding workflow from the beginning, it makes it much easier to keep the speed without taking on unnecessary risk.