How to secure vibe-coded apps: A production checklist

Anyone can vibe-code an app now-a-days. Equipping that app to run in production, however, with authentication, access control, server-side secrets, input validation, dependency scanning, audit logging, is not something that just anyone can do. And most vibe-coding platforms won’t do it for you either. Follow along to learn two ways to secure your team’s vibe-coded apps: the long, manual way, and the simple, scalable way in Retool.

TL;DR: Vibe-coded apps aren't production-ready out of the box. You could secure them by hand and it's an eight-part project you build and maintain yourself—not to mention do again for every app you build. Deploy into a governed platform like Retool, though, and your vibe-coded apps are secure by default.

What is a vibe-coded app?

A vibe-coded app is an application produced largely by describing what you want in natural language to an AI tool—Cursor, Lovable, Replit, v0, Claude Code—rather than writing most of the code by hand. The term was coined by Andrej Karpathy in February 2025, describing a workflow where you "see stuff, say stuff, run stuff, and copy-paste stuff, and it mostly works"—letting the model generate the implementation while you steer.

The appeal is obvious. The AI produces an app—or, at least, the bones of an app—in practically no time.

The problem, though, is equally obvious once you look closely. These tools optimize for "it works," not "it's secure." They generate plausible, functional code, but often skip the authentication, authorization, input validation, and secrets handling that production apps need.

Why vibe-coded apps are risky by default

You might think the risk of a vibe-coded app is that the AI will occasionally write a bad line of code, but it’s really not. It's that no human is reviewing thousands of generated lines before they reach production—and the generated code is measurably less secure than what careful engineers write.

AI-generated code can be inaccurate or incomplete

To be clear, the models have gotten much better than they were even a year ago, and they often ace the benchmark tests now. Those tests aren’t real software though.

On Scale AI's SWE-bench Pro, 1,865 real-world engineering tasks from professional codebases, the best frontier model resolves just 59% as of mid-2026, and most land between 40% and 55%, even though these same models clear 70% or more on standard benchmarks. Roughly half of realistic coding tasks still come back incorrect or incomplete. Code that looks finished and code that actually does the whole job are not the same thing.

AI-generated code often fails security tests

Veracode's Spring 2026 analysis found that even as AI coding assistants now write syntactically correct code more than 95% of the time, their security pass rate is stuck at roughly 55%—meaning nearly half of AI-generated code still contains a known vulnerability when no security guidance is provided, a number that has barely moved in two years.

Sensitive business data is being exposed

The consequences are already showing up in the wild. In May 2026, Axios reported that security firm RedAccess had found roughly 380,000 publicly accessible assets built with tools like Lovable, Base44, Replit, and Netlify—about 5,000 of which were leaking sensitive corporate data, from shipping schedules to clinical-trial records to unredacted customer-service transcripts. The apps weren’t hacked, they were simply published without anyone tightening access controls.

Enterprise leaders are feeling the exposure, too. According to Retool's AI governance report, 93% of senior technology and security leaders are at least somewhat concerned about vibe-coded tools running in production, and 38% rank them among their top operational risks.

The most common vulnerabilities in vibe-coded apps

Before the checklist, let's name what actually goes wrong. Most vibe-coding failures map directly to two Open Worldwide Application Security Project (OWASP) lists—the Top 10 for web apps and the Top 10 for LLM applications:

Hardcoded secrets and exposed API keys. The single most common recurring failure. Models happily paste credentials straight into client code.
Injection flaws. SQL injection, cross-site scripting (XSS), and command injection, usually because the model builds queries with string concatenation instead of parameterized statements.
Broken authentication and authorization. Context-dependent access logic is exactly the kind of thing AI gets subtly wrong, leaving routes open or roles unchecked.
Insecure and hallucinated dependencies. The model reaches for outdated packages, or invents ones that don't exist.

Two of these deserve their own attention because they're specific to AI-generated software:

Prompt injection in AI-generated apps

If your app passes untrusted content to an LLM—web pages, documents, emails, database records—an attacker can hide instructions inside that content and hijack the model's behavior. This is indirect prompt injection, and OWASP ranks prompt injection as the number-one risk in its Top 10 for LLM Applications. Any vibe-coded app with agentic behavior needs to treat all external content as untrusted input.

Hallucinated dependencies and supply-chain risk

Models sometimes recommend package names that sound real but don't exist. Attackers watch for these recurring hallucinations, register the invented names, and publish malware under them—a technique called slopsquatting (no, we’re not making that up).

When a developer trusts the suggestion and runs the install, the malicious package comes with it. The defense is simple to state and easy to skip: verify that every dependency actually exists, is maintained, and is the one you meant to install.

How to secure a vibe-coded app: the 8-step checklist

Securing a vibe-coded app by hand means working through all eight controls below—each one something you set up, wire together, and keep maintained. Here's the full checklist, in the order that matters. Notice how much of it is standing infrastructure, not a one-time fix.

If you deploy into a governed platform like Retool, most of this collapses. We'll get to that part right after.

Step 1: Write a security rules file

If your prompt never mentions security, your code isn’t going to feature it. The model fills the gap with whatever pattern it saw most in training, which is often an insecure one.

The fix is to give your AI tool standing security instructions through a rules file—CLAUDE.md, .cursorrules, .windsurfrules, or AGENTS.md—and to keep it current for every tool your team uses:

# CLAUDE.md / .cursorrules
- Validate and sanitize all user input on the server side.
- Verify every dependency exists and is actively maintained before adding it.
- Never hardcode secrets. Always use parameterized queries. Deny access by default.

A good way to build that file is to let the model help write it. Ask a capable model to security-review its own output, then codify whatever it flags into standing rules. Modern models catch a fair amount this way, but a model reviewing its own code shares its blind spots, so treat it as a head start, not a guarantee—the rest of this checklist is what runs underneath it regardless.

If you're building in Retool from the beginning instead of an external tool, this is still a worthwhile step. There's no separate rules file to maintain, but you'd still prompt with the same security intent, and input validation still stays yours. Either way, the app runs through the same governed runtime.

Step 2: Enforce authentication and access control

Broken authentication is one of the most common failures in AI-generated code, and doing it yourself is no joke. Standing up an auth layer, integrating an identity provider over OIDC or SAML, handling sessions, then building a roles-and-permissions model and enforcing a check on every route is quite the list of tasks. And your need to maintain all of it as the app grows.

At minimum, don't let the model hand-roll this. Prompt your AI tool to wire in a proven auth provider instead of custom login code. This will help, but it's still an integration you own and secure, app by app.

In Retool, this is automatic and configured. Every app you deploy sits behind Retool authentication with no unauthenticated path. You then turn on SSO and create permission groups and custom roles with additive role-based access control. The enterprise plan unlocks additional admin permission scopes for sensitive settings like SSO, billing, and audit logs, while lower tiers cover non-admin settings like theme editing and app drafts.

Step 3: Keep secrets server-side

Hardcoded credentials are the number-one recurring vulnerability in vibe-coded apps. By hand, closing this means standing up a secrets manager or environment-variable system, routing every credential through it, keeping keys out of client code and out of the repo, and rotating them on a schedule.

In Retool, credentials live on the resource, entirely server-side and injected at request time, so there's nowhere in the generated client code for a key to live. You can reference an external secrets manager with variables like {{ secrets.db_password }} (HashiCorp Vault integration), and the security checklist covers mapping credentials to environment variables.

Step 4: Prevent injection with parameterized queries

SQL injection, XSS, and command injection all trace back to code that works with trusted input and breaks under malicious input. Fixing it yourself means auditing every query, converting each to a prepared statement, and adding server-side validation and sanitization—never concatenating SQL, and never trusting the AI-generated frontend to validate.

In Retool, backend functions run server-side and {{ }} bindings compile to prepared statements, so parameterized input is the default rather than a discipline you enforce on generated code.

Step 5: Scan the code and its dependencies

Generated code expands your attack surface, and models invent packages that don't exist. Guarding against it means wiring static analysis (SAST), dependency scanning (SCA), and secrets scanning into CI, verifying every package is real and maintained, generating an SBOM, and triaging findings on every build:

npm audit --production          # flag known-vulnerable dependencies
# add a SAST step (CodeQL, Semgrep) and a secrets scan (gitleaks) to CI

Retool doesn't scan your source for you, so this stays in your hands. Instead, it shrinks the surface area. The server-side resource model keeps functions, connections, and credentials off the client, so the browser bundle exposes far less than a raw host would.

Step 6: Add audit logging

A freshly vibe-coded app has no audit trail, and building one is its own project. You’ll need to instrument every action, capture user, IP, query, and metadata, store and retain it for your compliance window, and ship it to your monitoring stack.

In Retool, every action is logged automatically—user email, IP, the exact function run, and metadata—and retained for a year (audit logs). On Enterprise, logs stream straight to Datadog or Splunk, and the logged events reference lists everything tracked, from QUERY_RUN to RESOURCE_CREATE.

Step 7: Use source control and separate environments

Editing a live app is dangerous anywhere, and worse when changes generate in seconds. The manual version of this step involves versioning the app with Git, setting up branching and pull-request review workflows, standing up separate dev, staging, and production environments, and building a promotion-and-rollback process.

In Retool, you connect a provider—GitHub, GitLab, Bitbucket, AWS CodeCommit, or Azure Repos—through source control and protect the app so changes move onto branches you review as pull requests and merge to deploy. This one is available on Retool's Enterprise tier.

Step 8: Deploy and govern the whole thing yourself

Even with Steps 1–7 done, you're not finished. You still have to host the app, wire all seven controls together, keep them consistent, and gate risky operations by hand—requiring a human to approve, say, a write that changes a production record.

Then you do it all again for the next app, and the one after that. Secure your apps on your own, and you’re stuck owning and maintaining the whole stack, per app, forever.

Or you deploy into a platform where those seven controls are properties of the runtime and risky operations are held for approval automatically. That's the next section.

How to secure a vibe-coded app in Retool (in three steps)

Here's the same outcome without the eight-part project. We'll follow one example app the whole way: a Customer Success Console with accounts down the left with health scores, a portfolio view, and per-account panels for usage, tickets, and a status update.

Out of your coding agent, all the data in the app is fake. Here’s how to connect it to your production data and deploy it securely with governance built in.

What you'll need: the generated app (Claude Code, Cursor, or your own React), a Retool account, and your data sources ready to connect as resources.

Where you'll end up: the same console, in production, with the security controls from the checklist enforced by the platform.

Step 1: Bring your app in

Import the React app into Retool—upload a zip, or bring it in straight from your terminal through the MCP server. Your components, styling, and structure come across intact. It's the same app you built, now sitting inside a platform that can connect it to real systems and govern it.

Step 2: Point it at governed resources

Swap the mock data for your real resources. In the console, the health score and usage trend now come from Snowflake, open tickets from Postgres, and account status and notes from Salesforce—each a centrally managed resource whose credentials and permissions live in Retool, not in the code.

Step 3: Publish with roles and approvals

Hit Publish. Assign who sees what—the success team can edit, managers get view access, executives get a read-only roll-up. Audit logging is already on, and any function that writes to a system of record—like saving an account's status change from "At risk" to "Churning" in the Status & Notes panel—is automatically held for approval before it runs. You wrote none of that logic, and you can deploy to Retool cloud or your own VPC via self-hosting.

A couple of best practices still stay with you: the rules file and dependency scanning both happen before the app reaches Retool, so they live in your own tooling. Everything after deployment, the platform takes over.

Ready to ship a vibe-coded app safely?

Put it together and the eight-part security project becomes a short one. Generate the app wherever you like—Claude Code, Cursor, Lovable, Replit—then import it into Retool, point it at your governed resources, and publish. The customer success console that started out full of fake data now runs on real systems, behind SSO and RBAC, with every action logged and risky writes held for approval. You wrote the app, the platform wrote the security.

If your team is drowning in security reviews for vibe-coded apps, give Retool a try. Build with whatever tool you like, deploy onto a foundation that's governed from day one, and the review bottleneck goes away.