How to Secure an App You Vibe-Coded

If you built your app with Cursor, v0, Lovable, Replit or Bolt, you shipped something working in days. That speed is real, and so is the gap it leaves. AI coding tools optimise for working, not safe. They wire up the endpoint, render the form, deploy the function, and quietly skip the parts a security review would insist on.

This guide is for indie hackers and founders who vibe-coded an MVP and want to ship it without leaking customer data or racking up a surprise bill. Below are the eight holes we find again and again, why AI tools leave them, and how to close each one before launch.

Why AI-generated code is functional but not secure

A model trained on public code reproduces the shape of a feature, not the security posture around it. It has seen ten thousand POST /api/checkout handlers, most of which were tutorials that skipped auth. It will happily inline an API key it saw in a README. It defaults to permissive because permissive code runs without errors, and "runs without errors" is the signal it was trained to maximise.

The result: your app passes every manual test you throw at it, demos beautifully, and still has a server action anyone can call. Security holes are silent by definition. The OWASP Top 10 exists because these same categories of mistake have shipped for two decades: AI tooling just produces them faster.

The 8 security holes in most vibe-coded apps

Want the punchy version? See 8 security holes AI coding tools leave for the one-line-fix list. Below is the fuller treatment.

1. Leaked API keys

The single most common finding. A key gets pasted into a config file, committed, and pushed to a public repo, or inlined into client code where any visitor can read it. Once a key is in git history, rotating it is the only fix; deleting the line does nothing.

Fix: keep secrets in environment variables, never in committed files, and scan your repo for leaked keys before and after every push.

2. Server actions and API routes with no auth check

Next.js server actions and API routes are just functions exposed to the internet. AI tools wire up the happy path (submit button calls action, action writes to the database) and forget to ask who is calling. Anyone who finds the endpoint can invoke it.

Fix: every action and route that reads or writes user data must verify the session first. No exceptions.

3. Missing input validation

If a handler trusts whatever shape the request body arrives in, an attacker controls that shape. Forms wired without a schema (Zod or equivalent) are the usual culprit.

Fix: validate and parse every external input at the boundary; reject anything that doesn't match.

4. Secrets exposed through NEXT_PUBLIC_ env vars

Anything prefixed NEXT_PUBLIC_ (or PUBLIC_) is bundled into the JavaScript every visitor downloads. AI tools don't always know which keys must stay private, and a service-role key in a public var is game over.

Fix: audit every public-prefixed variable; only truly public values belong there.

5. Permissive database policies (RLS)

For Supabase apps, Row-Level Security is the frontline. AI-generated policies often look right but allow far more than intended, sometimes a plain select against your auth.users table. See the Supabase RLS docs for what correct looks like.

Fix: test each policy as an unauthenticated and as a wrong-user request, not just as yourself.

6. Unmetered AI and billing endpoints

An /api/chat route with no rate limit or auth is an open invitation to run up your OpenAI or Anthropic bill. These endpoints are catnip for abuse because the cost lands on you.

Fix: require auth, add per-user rate limits, and cap spend at the provider.

7. Secrets leaking into the client bundle

Server functions that return entire env objects, or include secret values in error messages, ship those secrets straight to the browser.

Fix: never return raw config or verbose errors to the client.

8. No rate limiting

Without limits, login, signup, and expensive endpoints are open to brute force and abuse. AI scaffolds rarely include them.

Fix: rate-limit anything sensitive or costly.

Tool-by-tool: where each AI builder slips

The pattern of mistakes shifts by tool. We keep a dedicated checklist for each:

• Cursor: inlined keys and unguarded server actions. Is Cursor code secure? · Cursor audit
• v0: server-action auth and prop-driven fetches. The v0 security checklist · v0 audit
• Lovable: Supabase RLS and service-role keys. Lovable + Supabase pitfalls · Lovable audit
• Replit: secrets outside the Secrets tab, public Repls. Is Replit code secure? · Replit audit
• Bolt: open API routes and unvalidated handlers. The Bolt security checklist · Bolt audit
• Antigravity: over-scoped IAM and open functions. Is Antigravity code secure? · Antigravity audit

Your pre-launch security checklist

Run this list before you ship:

1. No secrets in committed files or git history.
2. Every server action and API route checks the session.
3. Every external input is schema-validated.
4. No private values behind a NEXT_PUBLIC_ prefix.
5. Database policies tested as a stranger, not as the owner.
6. AI and billing endpoints are authed and rate-limited.
7. No env objects or verbose errors returned to the client.
8. Rate limits on login, signup, and expensive routes.

Check yours in two minutes

You don't have to grep for all of this by hand. Run a free key-leak scan on your public repo right now, and for a full review across all eight categories, book a Launch scan: we read the code, find what's exposed, and open pull requests with the fixes in plain English.

Shipping fast is the whole point of vibe coding. Closing these eight holes is what keeps "shipped fast" from becoming "leaked fast."