Vibe Coding Security Risks: What AI-Built Apps Often Miss

The risks below aren't unique to any single tool — Lovable, Bolt, Cursor, v0, Replit and raw ChatGPT output all share them. The pattern is consistent: the model writes the feature, demonstrates the happy path, and quietly omits the controls that only matter when someone misuses the app. Knowing the pattern is most of the defense.

1. Authorization that lives only in the UI

The most frequent gap is access control implemented in the frontend. The model hides an admin action behind a role check in React, but the API route or database query behind it stays open. Because the model treats the visible UI as the source of truth, it rarely adds the matching server-side gate.

• Authentication and authorization must both run on the server for every sensitive action.
• Never trust a role, userId, or tenantId that arrives in the request body — derive it from the verified session.
• A hidden button is a UX choice; the real control is the check the server performs.

2. Secrets that leak into the client

AI tools inline keys where it's convenient and lean on public environment variables, which ship to the browser. The result is service-role keys, secret API keys, and webhook secrets sitting in a bundle or in git history.

• Separate public keys (publishable Stripe key, Supabase anon key) from private ones (service role, secret keys, webhook secrets).
• Scan the repo and history for sk_live_, service_role, JWT secrets, and provider tokens.
• Rotate anything that was ever committed — removing it from the latest commit is not enough.

3. Unsafe API routes and IDOR

Generated routes often query by an ID from the URL without checking who owns the record. That's an insecure direct object reference (IDOR): change the ID, read someone else's data. The same routes frequently skip input validation, trusting whatever the frontend sends.

1. Scope every ID-based route by the authenticated owner or workspace, not just the requested ID.
2. Validate request bodies against a schema and reject unexpected fields before writing.
3. Return 404 for inaccessible records so you don't leak their existence.

4. Missing rate limits and cost controls

AI-built apps love to expose AI. A public route that calls a model — with no rate limit and no usage ceiling — is both an abuse vector and a financial one. Auth, upload, and email routes have the same problem on a smaller budget.

• Add per-IP and per-account rate limits to public, auth, upload, and AI-backed endpoints.
• Set hard usage caps so a loop or a bot can't generate a four-figure bill overnight.
• Return a clear 429 instead of failing silently.

5. Payment and webhook handling that trusts the client

When AI writes billing code, it tends to parse the webhook body before verifying the signature, trust the amount or plan sent from the browser, and process duplicate events. Any of these can mean forged upgrades, double charges, or granting paid access for free.

• Verify the provider signature against the raw body before acting on a webhook.
• Derive the plan and price from the provider, never from request data.
• Make handlers idempotent so retries and replays are harmless.

6. Weak logging, error handling, and data hygiene

Two failure modes show up here. First, the app logs too much — full request bodies, tokens, or passwords — creating a secondary data-leak surface in your logs and error tracker. Second, it handles errors by leaking internals: stack traces and database messages returned straight to the user.

• Scrub secrets and personal data out of logs and error reports.
• Return generic error messages to users; keep the detail in private, access-controlled logs.
• Add error and empty states so a failure renders a sensible screen instead of a crash.

7. The launch-readiness layer the model never adds

Beyond vulnerabilities, vibe-coded apps tend to ship without the operational basics: no robots.txt or sitemap, broken links, layouts that break on mobile, no privacy page, and no GDPR-minded handling of the data they collect. None of it is glamorous, and all of it is expected at launch.

• Technical SEO: robots.txt, sitemap.xml, canonical metadata, one H1 per page.
• Working links and a responsive layout verified on a real phone viewport.
• A privacy page, honest analytics/consent handling, and a security contact.

AI coding tools are a genuine superpower for shipping. Treat their output the way you'd treat a fast first draft from a talented junior: review the security-relevant parts deliberately before launch, and you keep the speed without inheriting the blind spots.