Vibe coding security risks, and how to fix them
AI-built apps fail security in the same handful of ways. What they are, the evidence behind each, and how to check and fix your own app before real users find them.
The main security risks of vibe coding are database tables with missing or loose access rules, secret keys shipped to the browser, business logic that trusts whatever the browser sends, dependencies nobody checked, and AI features that can be talked into doing the wrong thing. They happen because an app built by prompting is judged by whether it works, and insecure code works perfectly well. As of 30 September 2026, the most recent large study, Veracode's 2026 GenAI Code Security Report, found AI models chose a secure option in only 56% of coding tasks, barely changed from 55% a year earlier.
This guide explains each risk, shows how to check your own app for it, and says what fixing it involves. It applies to any AI app builder or coding assistant, including Lovable, Bolt, v0, Replit and Cursor. Sources are listed at the end.
Is vibe coding secure?
Not by default. Vibe coding means building software by describing it to an AI and accepting the code it writes, judged by whether the result works. Security flaws rarely show up that way: a table anyone can read looks exactly like a table only its owner can read, until someone tries.
The models are getting better at writing code that runs, not code that is safe. Veracode found that AI-generated code now compiles nearly every time, yet the security pass rate has stayed flat. The best model it tested scored 68%, which still means one secure-coding task in three went wrong. The tools themselves say as much: Lovable's documentation states that you are responsible for making sure your app meets the security requirements of its use case, and that its scans do not replace a thorough security review.
What are the biggest security risks in vibe-coded apps?
| Risk | What it looks like | How to check |
|---|---|---|
| Broken access control | Row-level security off, or a policy that lets every user through | Sign in as user A and request user B's rows through the API |
| Exposed secrets | A service role or payment key in the browser bundle or the repository | Search the built JavaScript and the Git history for key prefixes |
| Trusting the browser | Prices, plans or roles decided in front-end code | Call the server function directly with a changed price or role |
| Injection and unsafe output | User text rendered as HTML, or written unescaped into logs | Submit markup and control characters in every form field |
| Unvetted dependencies | Packages the AI suggested that nobody checked, or that do not exist | Audit the dependency list against the registry and known advisories |
| Unsafe AI features | Prompt injection, agents with too many permissions, no spending cap | Feed the feature hostile instructions and watch what it tries to do |
| No way to notice or recover | No logs, no alerts, no tests, no rollback | Ask who would know if data leaked tonight, and how |
Why do vibe-coded apps leave data exposed?
Because in most AI-built apps the browser talks to the database directly, so the database's own rules are the only thing between a stranger and your users' data. On Supabase, which most AI app builders use, those rules are row-level security policies. Supabase's documentation says to enable RLS on every table in an exposed schema. Without it, the table is open to anyone holding the app's public key, as far as the table's grants allow, and by default that usually means reading and writing all of it.
This is not hypothetical. CVE-2025-48757, published in the US National Vulnerability Database in May 2025 with a critical score of 9.3, describes insufficient row-level security policies in sites generated by Lovable up to 15 April 2025 that let unauthenticated attackers read or write database tables. Lovable disputes it, saying each customer is responsible for protecting their own app's data. The researcher who reported it, Matt Palmer, says he scanned 1,645 projects and found 303 vulnerable endpoints across 170 of them.
We see the same pattern in prototypes we inherit. In the Bell prototype, the review of its row-level security rules covered about 12 of its 143 tables. In Looph, three privileged database functions could be called by any signed-in user; they were found and closed, and every one of Looph's 172 tables now has row-level security. The Looph case study describes how.
How do secrets leak from vibe-coded apps?
A secret is any key that grants access: a database service key, a payment key, an AI provider key. Assistants put them wherever the code needs them, which is sometimes the browser or a committed file. GitGuardian's State of Secrets Sprawl 2026, published 17 March 2026, counted 28.65 million new hard-coded secrets on public GitHub in 2025, up 34% on the year. It found commits made with Claude Code leaked secrets at a rate of 3.2%, against a 1.5% baseline across all public commits, and leaks of AI-service keys rose 81%.
On Supabase the rule is simple. The publishable (anon) key is designed to be public and only reaches what row-level security allows. The service role key bypasses every policy and must never leave the server. Our entry on the Supabase anon key vs service role key explains the difference; if a secret key was ever shipped or committed, rotate it, because deleting the line does not remove it from history.
What is slopsquatting, and why does it matter?
Slopsquatting is registering a software package under a name that AI models invent. When an assistant confidently imports a library that does not exist, an attacker can publish a malicious package with that name and wait. A study by Spracklen and colleagues, presented at USENIX Security 2025, generated 576,000 code samples with 16 models and found that at least 5.2% of the packages suggested by commercial models and 21.7% of those from open-source models did not exist. It recorded 205,474 unique invented package names.
The defence is ordinary engineering discipline: pin versions, keep a lockfile, check that every new dependency is real, maintained and needed, and run an audit for known vulnerabilities on every change rather than once before launch.
What new risks do AI features and agents add?
An app that calls an AI model inherits a new class of problems, catalogued in the OWASP Top 10 for LLM Applications 2025. Three matter most for small teams:
- Prompt injection (LLM01): text from a user, an email or a web page that makes the model ignore your instructions.
- Excessive agency (LLM06): an AI feature or agent allowed to do more than the task needs, such as delete records or send messages.
- Unbounded consumption (LLM10): no limit on how often the model can be called, which turns abuse into a bill. Rate limiting and a hard spending cap are the fix.
Give each AI feature the narrowest permissions it needs, treat everything the model reads as untrusted, and require a person to approve anything irreversible. Bell, an AI email assistant we engineered and which is still pre-launch, treats every email as hostile and has hard daily limits on AI spend; its database refuses any send that no person asked for or approved.
How do you make a vibe-coded app secure?
- 01Test access with two accountsCreate two users and try to read, change and delete each other's data through the API, not the screens. Anything that succeeds is a leak.
- 02Hunt for secretsSearch the built JavaScript and the whole Git history for secret key prefixes. Move every secret to the server and rotate anything that was ever exposed.
- 03Move decisions to the serverPrices, plans, roles and limits must be decided by server code and enforced by the database, never by the browser.
- 04Check every dependencyRemove what you do not use, confirm the rest are real and maintained, and run an audit on every change.
- 05Fence in the AICap spending, rate-limit calls, narrow each tool's permissions and keep a person in the loop for anything irreversible.
- 06Make failures visible and reversibleAdd an audit log, error monitoring, automated tests, a staging copy and a rehearsed rollback.
- 07Repeat on every changeEvery new prompt can widen a policy or add a key. Security is a habit, not a launch task.
For a Lovable app, our Lovable security checklist turns these steps into specific tests against Supabase's own advisors. The free production-readiness check scores your app out of 100 in 19 questions and names the three risks to fix first.
Plans start at $2,999 a month paid annually, or $3,999 month to month; see pricing.
Sources
Each fact above comes from one of these pages, checked on 30 September 2026.
- Veracode: 2026 GenAI Code Security Report, 28 Jul 2026, and 2025 GenAI Code Security Report, 30 Jul 2025 (veracode.com).
- US National Vulnerability Database: CVE-2025-48757 (nvd.nist.gov); Matt Palmer: Statement on CVE-2025-48757 (mattpalmer.io).
- GitGuardian: The State of Secrets Sprawl 2026, 17 Mar 2026 (blog.gitguardian.com).
- Spracklen et al.: We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs, USENIX Security 2025 (arxiv.org/abs/2406.10279).
- OWASP: Top 10 for LLM Applications 2025 (genai.owasp.org).
- Supabase documentation: Row Level Security (supabase.com/docs); Lovable documentation: Security scan (docs.lovable.dev/features/security).
- Case-study facts: our Bell and Looph case studies, as published on this site.
Common questions
Is vibe coding safe for a production app?
Only after the code has been reviewed and hardened. Vibe coding is a fast, reasonable way to build a first version, but AI-generated code often ships with loose access rules, exposed keys and untested logic, so check those before real users and real data arrive.
Does Lovable check my app for security problems?
Lovable runs a quick security scan every time you publish, covering database access rules, dependencies and MCP servers, and offers a deeper scan on request. Its documentation says the scans do not replace a thorough security review and that you remain responsible for your app's security.
Are AI coding tools getting more secure?
Slowly, if at all. Veracode's 2026 report found an average security pass rate of 56%, against 55% the year before, even though the code now compiles nearly every time. The best model it tested reached 68%.
What is slopsquatting?
Slopsquatting is publishing a malicious package under a name that AI models tend to invent, so that developers who install whatever the assistant suggests pull in the attacker's code. Checking that every new dependency is real and maintained prevents it.
How can I tell if my vibe-coded app is secure?
Test it the way an attacker would: sign in as two users and try to reach each other's data through the API, search your built code for secret keys, and call server functions with changed prices or roles. Anything that works when it should not is a finding.
More on this: Production architecture & security
Built something in Lovable you want people to rely on?
We are the engineers who take it the rest of the way — secured, tested, released and supported.