AI Summary
No, vibe-coded applications aren't safe to launch by default. Veracode tested more than 100 large language models and found that AI introduced a known OWASP Top 10 flaw in 45% of coding tasks, and the most widely reported vibe-coding failures share one root cause: a security control that ran where the user could reach it. This vibe coding security checklist covers four trust boundaries (bundle, database, endpoint, input) with a runtime test you can run yourself before you take a paying user.
In March 2025, Leo Acevedo posted that he'd built his SaaS product Enrichlead using Cursor with zero hand-written code. Two days later he posted again. He was under attack, with API keys maxed out, users bypassing the subscription, and junk piling up in his database.
Nothing sophisticated happened to him. Curious users opened browser dev tools and found that every security control in the app lived on the client side.
The paywall was a JavaScript check. The API key sat in the frontend bundle. Neither survived a reader who knew where to look.
Vibe coding is building software by describing what you want to an AI tool and shipping what it produces, with little or no line-by-line code review. It went from a niche term to Collins Dictionary's word of the year for 2025, and it works. That's the problem.
The tools optimize for one question: does the feature run when you click it? They don't ask whether it holds up when someone edits the request on the way out.
That gap isn't a founder failure. It's a property of how the tools work, and you can test for it in an afternoon.
In This Guide
Why does AI-generated code have security vulnerabilities?
AI-generated code has security vulnerabilities because security requirements are almost never in the prompt. As Veracode's CTO put it, developers don't have to specify security constraints to get working code, which leaves those decisions to the model.
The measurements are consistent across independent studies:
Empirical Evidence on AI Code Security (2025–2026)
| Finding | Source | Date | Sample |
|---|---|---|---|
| AI introduced a detectable OWASP Top 10 flaw in 45% of coding tasks | Veracode 2025 GenAI Code Security Report | Jul 2025 | 80 tasks, 100+ LLMs |
| Security pass rate still sits near 55%, flat across two years of model releases | Veracode Spring 2026 Update | 2026 | 150+ models |
| AI-co-authored pull requests carried 1.7x more issues, 2.74x more XSS, and 1.91x more insecure direct object references | CodeRabbit State of AI vs Human Code Generation | Dec 2025 | 470 open-source PRs |
| 19.7% of AI-recommended packages didn't exist, at 5.2% for commercial models and 21.7% for open-source | USENIX Security 2025 (Spracklen et al.) | 2025 | 576,000 code samples |
Two things follow from this data. Bigger and newer models haven't closed the gap, so upgrading your tool won't fix it. And commercial assistants hallucinate packages far less often, so if you built on Cursor or Claude your dependency risk is closer to 1 in 20 than 1 in 5.
There's a second gap the numbers don't show. A developer reading AI output notices the missing authorization check. A founder reading the same output sees the feature working and has no way to know a decision was made at all.
What is the Trust Boundary Audit?
The Trust Boundary Audit is a four-part pre-launch review that asks one question of every security control in your app: does this control run somewhere the user can reach it? If it does, it isn't a control. It's a suggestion.
It works as a vibe coding security checklist because that one question collapses a long vulnerability list into four things a non-engineer can check in about 45 minutes.
The Four Trust Boundaries Overview
| # | Boundary | What's on the wrong side | Pass criteria | Time |
|---|---|---|---|---|
| 1 | The Bundle | Keys, secrets, and tokens shipped to the browser | Zero credential matches in your frontend source | 5 min |
| 2 | The Database | Tables readable without row-level rules | Zero tables returned by the RLS query | 2 min |
| 3 | The Endpoint | Authorization checked in the UI, not the server | 403 on every cross-user and unauthenticated request | 15 min |
| 4 | The Input | Validation, signatures, and limits applied client-side | Malformed input rejected, 429 on flood, bad webhook refused | 20 min |
Work them in order. Each boundary is a gate that makes the next one meaningful. There's no point checking whether User B can read User A's records if your database has no row-level rules, because at that point everyone can read everything.
Working from a codebase you didn't write and can't fully read?
That's the common thread in every case study above. Schedule an architecture audit with our US-led engineering team.
Boundary 1: The Bundle
Everything shipped to the browser is public. AI tools hardcode credentials into frontend code because it makes the feature work immediately, and nothing in the generation step flags it.
Test it: Open your deployed app in Chrome and press F12. In the Sources tab, search the loaded files for sk_live_, service_role, SECRET, and API_KEY. Any match is already compromised.
This is how Moltbook came apart. Wiz researchers found a Supabase key in client-side JavaScript within minutes of browsing the site as ordinary users. That key gave unauthenticated read and write access to the whole production database, exposing 1.5 million API tokens and 35,000 email addresses.
Fix it: Rotate every key you find. Assuming nobody copied it isn't a security posture. Move secrets into server-side environment variables and confirm .gitignore covers them, so your commit history doesn't leak what the bundle no longer does.
Boundary 2: The Database
Row Level Security decides whether your database enforces ownership or trusts whoever asks. Supabase and Firebase both ship with public client keys by design, and those keys are only safe when row-level rules are switched on.
Test it: Open your SQL editor and run:
A production database should return zero rows. Every table listed is readable by anyone holding the key that's already in your frontend. Firebase users should check that no collection allows unrestricted read or write.
This is the single most documented failure in vibe-coded apps. CVE-2025-48757, rated critical, covers insufficient row-level security in Lovable projects that let unauthenticated attackers read or write arbitrary tables in generated sites. Lovable disputed the CVE on the grounds that each customer is responsible for their own application's data, which is worth sitting with: even in the vendor's own account, this one is yours.
Fix it: Enable RLS on every public table, then write an ownership policy such as USING (user_id = auth.uid()). Enabling RLS without a policy locks the table entirely, so add both together and retest the app afterward.
Boundary 3: The Endpoint
Broken access control is the hardest failure to see, because the app looks right. It checks that you're logged in. It doesn't check that the record you asked for belongs to you.
Test it: Log in as User A and copy a private URL such as /api/notes/42. Open an incognito window, log in as User B, and request that same URL.
Anything other than a 403 is a live data leak. Then try /admin, /dashboard, and /.env with no session at all, and watch what loads.
This is the top-ranked risk in the field. A01:2025 Broken Access Control held its number one position in the current OWASP Top 10, where 100% of applications tested showed some form of it.
Fix it: Every endpoint returning a record must compare the authenticated user ID against the record owner before it responds. Role checks belong in the same place, not in whichever component renders the admin button. Hiding a button isn't access control.
Boundary 4: The Input
AI-generated forms validate in the browser. That validation vanishes the moment someone talks to your API directly, which takes one command.
Test it: Send a POST request to your API with curl, putting <script>alert(1)</script> in a text field, and see whether it gets stored. Fire 100 failed logins in a loop and confirm you get a 429 back. Post a fake "payment succeeded" payload to your webhook URL and confirm it's refused.
Fix it: Validate and sanitize on the server with a library like Zod. Verify webhook signatures using your provider's method, such as stripe.webhooks.constructEvent(). Add rate-limiting middleware to every authentication and write route.
The boundary you don't control
Not every risk is yours to fix, and it helps to know which. In July 2025, Wiz found a critical authentication bypass in Base44, the vibe coding platform Wix had acquired weeks earlier.
Supplying a non-secret app_id to undocumented registration endpoints let anyone create a verified account on a private application, defeating the platform's own controls including SSO. Wix patched it within 24 hours and found no evidence of exploitation.
No customer configuration could have prevented that one. It sat below anything a Base44 user could see, which is the trade you make on a managed platform. Ask a vendor about their disclosure history before you build a business on them.
Why won't a security scanner catch these?
Static scanners find patterns, not permissions. Tools like Semgrep and CodeQL read your source without running it, so they're good at spotting a hardcoded string and blind to whether User B can read User A's record.
That distinction decides what you find before launch:
Static Scanning vs. Runtime Testing Matrix
| Static scanning catches | Only runtime testing catches |
|---|---|
| Hardcoded credentials and keys | Broken object level authorization (BOLA/IDOR) |
| Known-vulnerable dependency versions | Row-level security disabled in the live database |
| Unsafe function calls and injection patterns | Admin routes reachable without a session |
| Missing output encoding | Client-side-only paywalls and role checks |
| Insecure configuration defaults | Race conditions between concurrent requests |
Authorization is a property of state, not syntax. A scanner reading getNote(id) can't know whether the system enforces ownership, because that depends on who's asking and what's in the database right then.
So a clean scan report can sit alongside an app that leaks every record. The scan was accurate about what it measured. It never measured what breaks first.
Run both. Static scanning is cheap and clears the left column in minutes. The right column needs a second login and a willingness to poke.
What is slopsquatting?
Slopsquatting is a supply chain attack that exploits AI hallucination instead of human typos. When a model recommends a package that doesn't exist, an attacker registers that name on npm or PyPI with malicious code and waits for the next developer to install it.
The USENIX Security 2025 research catalogued 205,474 unique fabricated package names and found the hallucinations repeat rather than scatter, which is what makes pre-registration worth an attacker's time. Supply chain failures are now their own entry in the current OWASP Top 10, at A03:2025.
Test it: Run npm audit or pip-audit before you deploy. For any package your AI suggested that you don't recognize, open its registry page and check for download history and a real maintainer.
Fix it: Commit your lockfile so builds stay reproducible, and treat every AI-suggested import as unverified until you've confirmed the package exists. This takes ten minutes, and a malicious package runs its install script before you read a single line of it.
What does an unaudited app cost you commercially?
Security debt stops being a technical problem the moment you sell to someone with a procurement process. Enterprise buyers send security questionnaires before contracts, often standardized ones like SIG or CAIQ, and those ask where access control is enforced and how you handle incidents.
We see this pattern often in EdTech and SaaS. A working product loses the deal not because it failed a test, but because nobody could answer the question.
The same thing happens in technical due diligence. A reviewer opens the repository, finds a codebase nobody on the team wrote, and prices the remediation into the terms. In education, FERPA and COPPA obligations attach to student data no matter who wrote the code, and GDPR Article 32 requires appropriate technical measures for anything touching EU users.
Enrichlead is the cautionary version of this. The app didn't survive the incident.
Failed a boundary and unsure what the fix takes?
Book a 30-minute readiness review with Taylor Basilio or our senior engineering team.
Frequently asked questions
The most common are broken access control, exposed credentials in frontend bundles, missing server-side input validation, and disabled database row-level security. AI optimizes for working features rather than adversarial conditions, so it hardcodes secrets and skips ownership checks unless your prompt demands them explicitly.
Run four checks. Search your deployed frontend bundle for API keys, confirm row-level security is enabled on every database table, log in as a second user and try to open the first user's private URLs, then hit your API directly with unvalidated input. Anything that succeeds is a live vulnerability.
Open your Supabase SQL editor and run SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND NOT rowsecurity;. This query returns every public-schema table with row-level security disabled. A production database must return zero rows, because any table it lists is readable and writable by anyone holding the publishable key already in your frontend bundle.
Usually no. Exposed secrets, missing RLS policies, and absent rate limiting are configuration fixes measured in days, not rewrites. A rebuild becomes the honest answer only when authorization was designed client-side throughout, because retrofitting server-side ownership into that structure touches nearly every endpoint.
Platform choice matters less than review. Lovable added a built-in security scan in 2025, though scanners of that kind flag whether a rule exists rather than whether it actually blocks access. Every AI builder writes code that functions before it writes code that defends itself, so run the boundary tests regardless of tool.
Run the vibe coding security checklist before someone else does
Vibe coding earned its place by collapsing the cost of finding out whether an idea works. What it doesn't give you is the security layer a working demo never needed, and that gap is where Enrichlead and Moltbook both landed.
The four trust boundaries take under an hour. Run them before your first paying user, not after a researcher emails you. What you find is usually a configuration fix, and always cheaper than fixing it under disclosure.
Hireplicity has spent 18 years building secure software for EdTech and SaaS companies, with US-based engineering oversight and OWASP Top 10 scans on every pull request. If your app failed a boundary, or you'd rather someone checked the ones you can't, talk to us about a readiness review.
Validate Your App's Security Boundaries Before Launch
Schedule a 30-minute pre-launch security review with Taylor Basilio. We will evaluate your frontend bundle, database RLS rules, and server authorization endpoints, delivering a written remediation report in 48 hours.
Sources & References
- Pivot to AI — Guys, I'm under attack: AI vibe coding in the wild (Enrichlead Incident) (March 2025) — https://pivot-to-ai.com/2025/03/18/guys-im-under-attack-ai-vibe-coding-in-the-wild/
- The Register — Lovable app vulnerabilities & Vibe Coding Word of the Year 2025 (February 2026) — https://www.theregister.com/2026/02/27/lovable_app_vulnerabilities/
- Veracode — 2025 GenAI Code Security Report (July 2025) — https://www.veracode.com/blog/genai-code-security-report/
- Veracode — Spring 2026 GenAI Code Security Update (March 2026) — https://www.veracode.com/blog/spring-2026-genai-code-security/
- CodeRabbit — State of AI vs Human Code Generation Report (December 2025) — https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report
- USENIX Security 2025 (Spracklen et al.) — We Have a Package for You: Comprehensive Analysis of Package Hallucinations in Code — https://www.usenix.org/publications/loginonline/we-have-package-you-comprehensive-analysis-package-hallucinations-code
- Wiz Security Blog — Exposed Moltbook Database Reveals Millions of API Keys — https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
- National Vulnerability Database (NVD) — CVE-2025-48757 Detail (Lovable RLS Vulnerability) — https://nvd.nist.gov/vuln/detail/CVE-2025-48757
- OWASP — OWASP Top 10 A01:2025 Broken Access Control — https://owasp.org/Top10/2025/A01_2025-Broken_Access_Control/
- Wiz Security Blog — Critical Vulnerability Discovered in Base44 (July 2025) — https://www.wiz.io/blog/critical-vulnerability-base44
