Security & Production Readiness
Vibe coding gets you to launch. This chapter makes sure you don’t regret it.
What This Is
Vibe coding is extraordinary at collapsing the distance between an idea and a working app. That's the magic. The trap inside the magic: the same AI that builds your app in a weekend builds it the way most first drafts get built — optimized for "it works," not "it's safe."
41% of all code written globally is now AI-generated. 63% of vibe coders are non-developers. That means an unprecedented number of real applications are reaching real users without ever going through a security review.
Security isn't a feature you add at the end. It's a set of constraints threaded through every layer — how you store passwords, read from your database, handle unexpected input, manage secrets. Good news: none of this requires a CS degree. It requires knowing the five or six failure modes that kill most applications, then making sure you've addressed each one before flipping the live switch.
This isn't a security textbook. It's a production readiness checklist in prose. The minimum responsible standard for any app handling real users, real data, or real money. Toy or demo for your own use? Relax some of this. Real people signing up and trusting you with their info? Every section below is non-negotiable.
Who Should Use This
Non-technical founders who've shipped or are about to. The platforms make deployment dangerously easy. They don't make security automatic. Difference between a successful launch and a screenshot that gets passed around.
Developers moving at vibe coding speed. Even experienced engineers slip when they're in flow and letting the AI handle large swaths. The AI generates code that passes your tests — and skips rate limiting on your login endpoint, returns more DB fields than the frontend needs, hardcodes a staging URL into prod.
The Six You Cannot Skip
1. Authentication and Authorization. Two different things. Authentication is who you are — login, sessions, password hashing. Authorization is what you're allowed to do — can this user see this record, edit this resource, delete this account? AI handles auth with reasonable defaults if you use a real library (Clerk, Auth.js, Supabase Auth). Authorization is where the gaps appear. Classic failure: an endpoint that checks "are you logged in?" but not "are you logged in as the person who owns this resource?" That's an Insecure Direct Object Reference (IDOR), and it's the most common vulnerability in vibe-coded apps.
If your app has URLs like /dashboard/orders/4582, ask: what happens when a logged-in user changes the number to 4581? They should get a 403. If they see someone else's data, you have a serious problem to fix before anyone else touches the app.
2. Environment Variables and Secrets. API keys, database connection strings, secret tokens — never in source code. Not "just for testing." Pattern that works universally: .env file locally (in .gitignore so it's never committed), environment variables on your hosting platform's dashboard. AI tools sometimes generate code with placeholder keys baked into files. Review everything the AI creates for anything that looks like a key. One accidental commit exposes credentials that stay valid for years if you don't rotate. GitHub auto-scans for leaked secrets — that notification means damage may already be done.
3. SQL Injection and Input Validation. Any input from users — form fields, URL params, search boxes, file uploads — that gets passed to a database query needs parameterized queries or a proper ORM between input and execution. SQL injection works by inserting database commands into form fields. A search box that builds a query by string-concatenating user input can be exploited by anyone who knows the trick — and returns every row in your database to a stranger.
Modern ORMs (Prisma, SQLAlchemy, ActiveRecord) protect against this by default. Raw string interpolation does not. When reviewing AI-generated DB code, look for any place where user-provided data is concatenated into a string that gets executed. Fix is usually two lines once you point at it.
4. Rate Limiting and Abuse Prevention. Cap how many requests a single IP or user can make to your API in a time window. Without it: login endpoint gets brute-forced, API gets scraped into unusability, AI-powered features (with per-call costs) get drained by one bad actor in an afternoon. Most modern hosting offers rate limiting at the infra level. Most frameworks have middleware for it.
Add it intentionally — not when your OpenAI bill spikes or your login endpoint shows 40K attempts from an unfamiliar IP range. Any endpoint that triggers an email, SMS, or paid external API call is especially important. Those are the endpoints that cost you real money when abused.
5. HTTPS. Every modern host — Vercel, Netlify, Railway, Render, Fly, Supabase — provisions TLS automatically. You don't configure it. What you do verify: HTTP traffic redirects to HTTPS, doesn't serve content on both. Check for "Force HTTPS" in your platform settings. Usually default. Takes ten seconds. Check it.
6. Dependency Auditing. Every package you install is code written by someone else running with the same permissions as your app. Outdated packages with known vulnerabilities are one of the most common attack vectors. Tools to catch this are free and take thirty seconds. Node: npm audit. Python: pip-audit. Run before launch. Make a habit of running monthly. GitHub's Dependabot automates the whole loop — opens PRs when vulnerable packages have updates available.
The Cost of Skipping
The free security tier is excellent. npm audit, pip-audit, OWASP ZAP, GitHub's secret scanning, Dependabot — cost nothing, almost no setup. Catches the majority of issues that take down real applications. Run them, follow the hardening above, use a reputable auth library instead of rolling your own, and your app is significantly more secure than the average vibe-coded project that went straight from "it works" to "it's live."
For payment info or sensitive personal data: paid tools add real coverage. Snyk for continuous monitoring and PR scanning. Semgrep for static analysis catching anti-patterns as you write. For applications at scale (thousands of users, regulated industries, enterprise sales) a third-party pen test ($3K–15K) is money well spent before a major launch.
Cost argument is straightforward. A breach involving even a few hundred users typically costs more in reputation damage, legal consultation, customer comms, and remediation than the entire dev budget of the app. The free tools take an afternoon. That's the trade.
Risk by Project Type
Web Apps — ★★★★★. Fully exposed to the public internet. Every endpoint is discoverable by automated scanners within hours of going live. Auth, authorization, rate limiting, input validation, HTTPS — all mandatory. Good news: web has the best ecosystem for addressing these. Every issue above is well-documented and often handled automatically by frameworks you're using.
Mobile Apps — ★★★☆☆. Different threat model. The installed app is harder to attack directly than a public endpoint, but the API it talks to has all the same vulnerabilities. Mobile-specific concerns: secure on-device token storage, no logging sensitive info to console in production builds, API validates the caller (don't trust requests from "the app").
Local Tools — ★★☆☆☆. Smaller attack surface. SQL injection and public rate limiting matter less when no external traffic reaches the tool. What still matters: don't hardcode secrets even in local tools, because they end up in Git and stay there. If there's any chance the tool gets exposed later via a tunnel or future deployment — build the auth layer now, not when the codebase is bigger.
Managed vs. Self-Hosted
Fully managed platforms (Lovable, Bolt, Base44, Replit deploys) absorb meaningful infra security. TLS handled. DDoS protection at the infra level. No web server config or OS patching. Genuine advantage for non-technical builders — security floor is higher because there's less for you to misconfigure. Some are going further: Lovable now ships built-in security scanning with a Wiz integration, which catches a real class of issues automatically. Run it. Don't mistake it for the whole job.
What managed platforms don't do: secure your application logic. They cannot know whether your endpoints check authorization correctly, whether you're leaking user data in API responses, whether your auth flow has gaps. That layer is yours regardless of where you're hosted. "The platform handles security" is true about TLS and infra. It's not true about the six things above.
Self-hosted (your own VPS, containers on Fly) gives more control and lower cost at scale. Pushes the infra security burden back to you — firewall rules, server patching, container security, DB access controls. For early-stage with non-technical founders: managed path is almost always right. Move to self-hosted when you have the expertise to manage it properly. Not before.
The Story
A friend built a client analytics dashboard for his small marketing agency using Replit and an AI agent. Generated the bulk of the backend in one afternoon. Genuinely impressive — clients log in, see campaign metrics, filter by date, export CSV reports. He was proud of it. Three clients were using it within a week of launch.
Two weeks later one of them called. She'd been poking around the URL out of curiosity — changed /dashboard/clients/7 to /dashboard/clients/6 and saw a completely different company's campaign data. She wasn't malicious. She called immediately. His stomach dropped.
Every client's data had been accessible to every other logged-in client. The backend checked "is this user authenticated?" but not "does this user actually own client ID 6?" Fix took 45 minutes. The AI had even written the authorization check correctly on a handful of other endpoints — just hadn't applied it consistently across all of them. The PR contained two lines of middleware that validated ownership before serving any record.
The lesson isn't that the AI did something catastrophically wrong. It's that authorization consistency requires deliberate, systematic review — not an assumption that if it works on one endpoint it works everywhere. He now runs a five-minute authorization sweep before every deploy.
Where It Bites
The AI won't proactively flag authorization gaps. It generates code that satisfies the requirement it was given. If you didn't specify "ensure users only access their own data," that constraint may simply be absent from the output. Security requires adversarial thinking — not "does this work?" but "what can someone do to break this, and what happens when they try?"
Training data includes old code. Security best practices evolve. Password hashing, token storage, OAuth flows — all changed in the last five years. When the AI generates auth code, a quick search to confirm the approach is still current is worth the thirty seconds.
Managed platforms create a false sense of security. Infra security and application security are different things. The platform handles one. You handle the other. Don't conflate them.
Gavin's Rule: Five-Minute IDOR Sweep Before Every Launch
Create a second test account on your app. While logged in as the second account, take every URL with a number or identifier —
/orders/4582,/profile/user123,/reports/17— and manually change the value to something adjacent. You should get a 403 or be redirected to your own data.If you see someone else's data, you have an IDOR vulnerability. Fix before launch.
Five minutes. Catches the single most common class of authorization bug in vibe-coded apps. Add it to your launch checklist. Run it every time you add a new resource type.
Bottom Line
Security in vibe coding isn't about perfection. It's about not having a preventable incident that undermines everything you've built. Use the free tools. Check authorization manually before launch. Keep secrets out of source code. Confirm HTTPS is enforced.
Free checklists catch what you remember to check. The CodeDR exam checks the failure modes vibe-coded apps actually ship with — keys, auth, deploy — and grades the repo on your machine.
— Gavin