Fix: vibe coding × security
The AI built everything you asked for.
The breach is in what you didn't.
A web developer on r/VibeCodeDevs put it in one line: 'AI does what you ask. It just never thinks about what you didn't ask.' The canonical story made the rounds on Hacker News — a founder's vibe-coded SaaS leaked its user list on the frontend, a hacker pulled the Stripe key and issued every customer a refund, and the founder is now hiring a developer to shore it up. You don't need to become a security engineer to avoid that ending. You need a base where the questions you didn't ask already have answers.
One pattern behind every AI-app breach
The tool barely matters. Veracode's 2025 GenAI code security report found AI assistants choosing insecure implementations in roughly 45% of test cases when given the choice. The failures rhyme everywhere: secrets in client code, tenancy checks that exist in some queries and not others, auth that renders a login screen without verifying API calls, webhook handlers that trust whatever arrives. The market already prices this pain — an entire 'vibe code rescue' industry now quotes its audits and patch jobs in the thousands of dollars, and the communities themselves turned strict: a 195-upvote r/vibecoding consensus calls releasing an unaudited AI-built backend to the public 'wildly irresponsible.' None of this says you were wrong to build the way you built. It says the app earned a real backend.
The 20-minute self-audit
Search your own bundle
Open your deployed app, view source, and search for 'sk_', 'secret', and 'key'. This takes two minutes and is the exact first move an attacker makes. Any hit means rotate the credential today.
Ask for someone else's data
Log in as yourself, note an ID in any API response, then request a different ID that isn't yours. If data comes back, you have a tenancy hole — and so does every account in your database.
Change your password, keep the old tab
Reset your password, then use a session that was already open. If it still works, stolen sessions survive your users' attempts to lock intruders out.
Replay a webhook
Send the same payment event to your webhook endpoint twice. If your app processes it twice — double credit, double email, double state change — real provider retries will do this to you in production.
Hammer your own login
Script 30 wrong-password attempts in a minute. If nothing throttles you, credential stuffing lists run against your users at full speed, and their reused passwords become your breach.
The wall: what attempt number five should look like
On useDeploy, auth endpoints sit behind their own rate-limit tier with two buckets — per IP and per email — so a stuffing run trips the wall no matter how it distributes traffic. It's one of several edges that fail closed: the answer to 'did anyone add throttling?' is yes, because it was there before your first commit.
1 $ ./stuff-credentials.sh [email protected] # 50 attempts
2 attempt 01 → 401 Unauthorized
3 attempt 02 → 401 Unauthorized
4 attempt 03 → 401 Unauthorized
5 attempt 05 → 429 Too Many Requests
6 attempt 50 → 429 Too Many Requests
7
8 # per-email limiter tripped; the per-IP tier was counting too.
9 # auth, read, and write traffic each have their own bucket.
Every audit item above, already closed
Nothing secret in the bundle
Secrets exist only in server-side env, validated by a Zod schema at boot — the server won't even start with a missing credential, and the client never receives one.
Someone else's ID gets a 404
Org-scoped repositories plus a Prisma query guard mean cross-tenant requests return 404 — not the data, and not even confirmation the resource exists.
Sessions you control from the server
Sessions are rows in Postgres, revocable at will. Ending all concurrent sessions when credentials change is a documented flag you enable — not a subsystem you build after an incident.
Webhook replays are absorbed
Incoming billing webhooks dedupe by externalOrderId over a durable outbox; outgoing webhooks are HMAC-signed so receivers can verify you sent them.
Auth with its hard parts done
2FA TOTP, magic links, OAuth, and organization-scoped RBAC with API keys — via BetterAuth, wired and tested rather than sketched.
450+ tests standing guard
The behaviors above are asserted by 450+ automated tests plus a Playwright E2E gate in CI. A change that reopens a closed gap fails the build before it ships.
Migration path: whichever tool built it
The pattern is the same across AI builders, so the migration is too. Export your code — every major tool has a GitHub sync or download. Keep the frontend where it earns its place; it usually does, because UI is what these tools are genuinely good at. Then rebuild the floor on the base, in order of blast radius: rotate every credential that ever touched generated client code, move data access behind the typed API where the tenant guard scopes every query, let BetterAuth replace whatever auth was improvised, and plug billing into the idempotent webhook pipeline. Your AI tool stays in the loop — the base ships agent rules, typed contracts, and lint-enforced boundaries precisely so you can keep building by prompt, now inside walls. If you know which tool built your app, the tool-specific guides cover Lovable, Bolt, v0, Replit, and Cursor in detail.
Vibe-coded apps × security, asked directly
Do I have to throw my app away?+
Which leak do I fix first?+
How is the base itself vetted?+
My tool isn't Lovable, Bolt, v0, Replit, or Cursor.+
One license. Two ways to own it.
CORE
Founder
A frozen snapshot of UseDeploy. Yours forever, no updates.
- Frozen-version zip download
- Full source, commercial use, unlimited projects
- All 800+ tests · all docs pages
- 14-day refund
LATEST + UPDATES
Lifetime
Always the latest UseDeploy. Re-download every release, free.
- Latest-version zip — re-downloadable forever
- Every future release at no extra charge
- Priority Discord support
- All 800+ tests · all docs pages
- 14-day refund
You built the app. Now close it.
Keep what you made — put it on a base where sessions, tenancy, secrets, and billing are already hardened and 450+ tests keep them that way.