Why vibe-coded apps ship with security gaps

A vibe-coded app is one built primarily with AI builders, no-code tools, or AI-generated code — Lovable, Bolt, Cursor, v0, Replit, Claude Code, and similar. The workflow is fast and prompt-driven: describe the feature, get something working, iterate. That is genuinely useful, and it is why a solo founder can now ship a real product in days instead of months.

What changes compared to a traditional build is the review surface. Code is generated faster than it is read. Defaults are accepted because the demo works. Configuration choices are made implicitly, not explicitly. None of this is a flaw of vibe coding — it is a feature of building quickly. It just means the pre-launch pass needs to be a normal step, not something that gets skipped because everything looks fine.

Almost none of the gaps in a vibe-coded app are exotic. They live in three predictable places:

• Defaults that work for a demo but are not safe for production

  An open database rule, a missing header, or a debug mode left on.

• Implicit choices that were never reviewed

  Which environment variables ship to the browser, which routes require login, what gets included in the public build output.

• Parts of the stack the AI did not touch

  DNS, platform settings, preview deployments, admin pages — things outside the prompt-driven loop.

A quick plain definition: launch readiness is the state where your app is safe for real users and real data, not just functional in a demo. Public exposure means information or files reachable without logging in. Most launch-readiness work is just confirming public exposure is intentional.

Across vibe-coded apps, the same four buckets keep showing up. They are not subtle, and they are not hard to fix once you know to look for them.

• Secrets in the frontend bundle

  Service keys and private tokens that should live on the server end up shipped to every visitor's browser.

• Sensitive routes that load without auth

  Dashboards or admin pages render for anyone with the URL, even though they show a login form.

• Database rules that allow public reads or writes

  Tables with real data are readable — sometimes writable — by anonymous requests.

• Missing browser protections

  HTTPS enforcement, framing protection, and content restrictions never get configured because the demo works without them.

For the deeper dives on each: see the public .env files and exposed secrets guide, authentication security checklist, Supabase RLS checklist, and HTTP security headers checklist.

A demo passes when the happy path renders for the person who built it. A launch is different. It assumes a stranger will arrive, try things the demo never did, and possibly misuse what they find. The gap between those two is where most launch-day incidents live.

The honest framing for founders: an app that works is the start of being ready, not the end. Functional plus a basic launch-readiness pass is the line for shipping to real users.

A practical pre-launch sweep is short. You are not trying to prove your app is unbreakable — you are trying to close the obvious gaps that any drive-by visitor could reach.

• Config or secret files (like .env, .git) return 404 on your live domain.

• Sensitive pages redirect or block when opened logged out.

• Database tables with real data are not readable or writable by anonymous requests.

• Your site is served over HTTPS with a valid certificate and core browser protections in place.

• Only the intended production deployment and domain are public.

• Privacy, terms, and a working contact method are published.

For the full sweep, work through the launch security checklist (the final pre-launch readiness pass) and the broader vibe coding security checklist (the nine-area review).

GuardMint runs a public, non-invasive scan of your live URL — the same surface any visitor sees. It is built for exactly this moment: a quick, honest read on whether the obvious gaps are closed. Our methodology explains how the scan works.

• Exposed files like .env, .git, and source maps reachable on your domain.

• Secret-looking keys and tokens visible in your frontend bundle.

• Missing or misconfigured security headers and HTTPS issues.

• Overly permissive CORS and weak cookie flags.

• Error responses that leak internal details about your stack.

A scan sees what is publicly reachable. The items below depend on access rules, code, or settings no external scan can confirm — they need you, a second test account, or a developer.

• Whether your authentication and authorization rules are actually correct.

• Whether per-user data access is enforced in the database, not just the UI.

• Whether admin and role-based access is restricted on every sensitive action.

• Whether business logic — billing, sharing, exports — behaves safely.

Why do vibe-coded apps ship with security gaps?

Because the tools that build them — AI builders, no-code platforms, AI-generated code — optimize for a working demo. They reliably render a UI and a login screen, but the parts that don't show up in the demo (secret handling, access rules, headers, platform settings) are easy to leave half-done. The result is an app that works perfectly until a stranger pokes at it.

Are vibe-coded apps less secure than hand-written apps?

Not inherently. The risk pattern is different. Vibe coding amplifies the cost of small mistakes because code is generated faster than it is reviewed, and defaults that work in a demo are kept without being questioned. With a basic launch-readiness review, vibe-coded apps can be just as safe as anything hand-written.

Is this an argument against using AI builders?

No. AI builders are powerful and let small teams ship real products quickly. The point is that fast shipping needs a basic, practical security pass before real users arrive — not that the tools are bad. Treat the launch-readiness review as a normal part of the workflow, not a punishment.

What kinds of security gaps are most common?

Four show up over and over: secrets visible in the frontend bundle, sensitive routes that load without authentication, database rules that allow public reads or writes, and missing browser-facing protections like HTTPS enforcement and framing protection. Each is usually a configuration fix, not a rewrite.

Can an automated scan catch all of these?

No. A public scan can spot what is reachable from the outside — exposed files, missing headers, leaky errors, secret-looking keys in the bundle. It cannot confirm that your access rules are correct, that admins are restricted, or that business logic behaves safely. Those still need human or developer review.