Here's the uncomfortable pair of statistics that defines security in 2026: 96% of developers say they don't fully trust AI-generated code to be functionally correct, yet barely half always review it before deployment. Multiply that by 41% of all global code now being AI-generated, and you get the current situation: an enormous volume of production software that nobody, human or machine, has actually vetted.
For solo founders this isn't abstract. Vibe-coded apps with real users and real payment data are getting breached in depressingly predictable ways. The good news: the vulnerabilities are predictable, which means the defenses are too. (Security is one item on the longer list of what AI builders leave unfinished; this article is the deep dive on that item.)
Why AI-generated code is insecure by default
Research from 2025 found roughly 45% of AI-generated code contains security flaws. The reasons are structural, not fixable with a better model alone:
- Models optimize for "works," not "safe." The training signal rewards code that runs and looks right. A missing authorization check runs perfectly.
- Security lives across files; generation happens per-prompt. Whether an endpoint is safe depends on middleware, session config, and database rules the model may never have had in context.
- The model mirrors your prompt's blind spots. Ask for "an endpoint that returns the user's invoices" and you'll get exactly that, often without the which user is allowed to ask part you didn't mention.
None of this means avoid AI code. It means AI code needs the same systematic skepticism you'd apply to a fast, confident junior developer with no security training.
The five vulnerabilities that actually show up
1. Missing authorization (not authentication)
The single most common hole in vibe-coded apps. Authentication ("is this a logged-in user?") usually works, because the boilerplate or auth library handles it. Authorization ("is this user allowed to see this specific record?") is generated per-endpoint, and models routinely skip it. The result: change the ID in the URL, read someone else's data. Test for this in an afternoon: log in as user A, request user B's objects by ID.
2. Secrets in client code
API keys pasted into frontend components, service credentials in public repos, admin tokens in localStorage. Models happily put a key wherever the prompt implies it goes. Anything shipped to the browser is public; anything in git history is public forever once the repo is.
3. Unvalidated input at the API layer
Generated UIs validate forms; generated APIs often trust whatever arrives. Anyone with curl skips your form. Every API route needs server-side validation of types, ranges, and ownership; a one-line rule in your CLAUDE.md ("validate all input at the API boundary with zod") fixes most of this at the source.
4. Permissive database rules
Supabase Row Level Security policies that allow all reads "to get it working," Postgres roles with table-wide access, MongoDB collections with no access rules. The model gets the demo working; the rules that made it work ship to production. Database-level rules are your last line of defense precisely because they hold even when the generated application code is wrong.
5. Silent failure of the security you think you have
Webhook signatures never verified, rate limiting configured but not attached, CSRF tokens rendered but not checked. Generated code is full of security theater: the shape of protection without the wiring. The only way to know is to test the failure case: send an unsigned webhook, replay a request, hammer the endpoint.
How audited boilerplates close the gap
A maintained boilerplate doesn't make your app secure; your custom features are still yours to get right. What it does is take the highest-stakes surfaces off the generation table entirely:
- Auth flows (sessions, password reset, OAuth) arrive implemented by a maintainer, reviewed by thousands of buyers, and patched as providers change. These flows are exactly where generated code fails most expensively.
- Payment integration ships with webhook signature verification and tested subscription-state handling: the difference between Stripe working and Stripe appearing to work.
- The patterns are already consistent, so your coding agent extends safe patterns instead of improvising new ones each session. This is the security half of agent-readiness.
The economics are lopsided: a $200 kit versus one incident. A single leaked customer dataset costs more in trust, cleanup, and (under GDPR) potential fines than every boilerplate on our catalog combined.
The 90-minute security pass every founder should run
Before launch, and again whenever the agent has touched auth or data access:
- The ID-swap test (20 min): as user A, request user B's resources by ID across every endpoint. Any success is a sev-1.
- The curl test (20 min): hit your API routes directly with missing fields, wrong types, and other users' IDs. The form is not your validation layer.
- Secret sweep (15 min): grep the client bundle and git history for keys. Rotate anything you find.
- Webhook forgery (15 min): send your webhook endpoint an unsigned payload. It should be rejected, not processed.
- Ask the agent to attack you (20 min): "Review this codebase as a penetration tester. List the five most likely vulnerabilities with file references." Models are notably better at finding holes when explicitly asked than at avoiding them while building.
Repeat step 5 weekly; it's the cheapest security audit in history and catches a remarkable share of issues introduced in routine feature work. For the broader review workflow this fits into, see our code review playbook for solo founders.
Frequently Asked Questions
How insecure is AI-generated code really?
Studies from 2025 found about 45% of AI-generated code samples contain at least one security flaw, with missing authorization checks and improper input validation the most common categories. The raw rate matters less than the workflow problem: only about half of developers consistently review AI output before deploying it, so flaws ship at scale.
Does using a boilerplate make my app secure?
It makes the riskiest 30% of your app (authentication, session handling, payment webhooks) start from audited, maintained code instead of fresh generation. The remaining 70% (your features, your queries, your permissions) is still your responsibility. A boilerplate raises the floor; it doesn't remove the ceiling.
What should I tell my AI coding agent to make its output safer?
Put standing rules in your CLAUDE.md or AGENTS.md: validate all input at the API boundary, check resource ownership on every read and write, never put secrets in client code, always verify webhook signatures. Standing rules beat per-prompt reminders because they apply even when you forget. Then separately ask the agent to review its own work as an attacker, since generation and review engage different behavior.
Do I need a professional security audit before launch?
For a typical pre-revenue SaaS, no: the 90-minute pass above catches the vulnerabilities that actually get exploited at small scale. Commission a professional audit when you handle regulated data (health, finance), sign your first enterprise customer with a security questionnaire, or pass roughly $10K MRR and have something meaningful to lose.