Vibe coding security comes down to a short list of gaps that AI builders leave open: secrets in the browser, missing access checks, unprotected databases and no way to see or undo damage. Most can be checked in a day and fixed in a few weeks, before real users and their data arrive.
Key takeaways
- AI tools write code that runs, not code that has been threat-modeled. Security is still your job.
- The most damaging gaps are about access: who can read which data, and which keys sit in the browser.
- If your app uses Supabase, Row-Level Security on every table is the single most important check.
- Every risk below has a quick test you can run yourself before paying anyone.
- Fix access and secrets first, then add the logging and backups that let you recover from what you missed.
Why vibe-coded apps are risky
Vibe-coded apps are risky because the AI optimizes for a working demo, and a demo never meets an attacker. The code passes the happy path, while the checks that stop a stranger from reading other users' data are often missing.
The numbers back this up. In Veracode's 2025 test of more than 100 language models on 80 coding tasks, the generated code introduced a security flaw in 45% of cases. Models failed to defend against cross-site scripting in 86% of relevant cases and against log injection in 88% (Veracode, July 2025).
The person prompting is the second gap. A founder can see that the sign-in page works, but not that the API behind it accepts any user ID. That is why the same handful of problems shows up across AI-built apps. If you are still choosing a builder, our comparison of Lovable alternatives covers how each one handles code and hosting.
12 vibe coding security risks and how to fix them
The twelve risks below follow the OWASP Top 10:2025 and the way AI builders set up apps. Each one has a quick check and the fix. Start from the top: the first four expose data, so they matter most.
1. Exposed API keys
What it is. Keys for Stripe, OpenAI, email or the database end up in the repository, often in an early commit the AI made before you asked for environment variables. GitGuardian counted 23.8 million secrets leaked on public GitHub in 2024, and 70% of those leaked in 2022 were still valid (GitGuardian).
How to check. Run a secret scanner such as gitleaks or GitGuardian over the whole Git history, not only the latest files.
How to fix. Rotate every key that was ever committed, since deleting the file does not remove it from history. Move keys to the hosting platform's secret store.
2. Missing authorization checks
What it is. The app checks that a user is signed in, but not that the record they ask for belongs to them. Change an ID in the URL or API call and you see someone else's order. OWASP ranks this, Broken Access Control, as the top web risk.
How to check. Sign in as user A, copy a request from the browser's network tab, and replay it with user B's record ID.
How to fix. Check ownership on the server for every read and write, in one shared function or database policy, not in each screen.
3. Supabase Row-Level Security turned off
What it is. Lovable, Bolt and many Cursor projects use Supabase, where the browser talks to the database directly. That is safe only with Row-Level Security (RLS). Supabase's own docs say to "enable RLS on every table in an exposed schema" (Supabase RLS). CVE-2025-48757 described Lovable projects whose weak policies let unauthenticated users read tables; Lovable disputes it (CVE record).
How to check. In the Supabase dashboard, open each table and confirm RLS is on and has policies. Then query the API with only the public key and no user session.
How to fix. Enable RLS everywhere and write policies per action (select, insert, update, delete) tied to auth.uid().
4. Secrets in client-side code
What it is. Different from a leaked repository: here the secret ships to every visitor's browser. Vite exposes any variable prefixed VITE_, and Next.js inlines NEXT_PUBLIC_ variables into the JavaScript bundle (Vite, Next.js). An AI that needs a key "to make it work" will often add the prefix.
How to check. Open the deployed site, view the JavaScript files in developer tools and search for sk_, secret and service_role.
How to fix. Only publishable keys belong in the browser. Supabase is explicit that a secret key "bypasses every Row Level Security policy" and must never be in a browser (Supabase API keys). Move calls that need secrets to a server function.
5. No input validation
What it is. Forms and APIs accept whatever arrives: negative prices, 10 MB names, HTML in a comment field. The frontend validates, but anyone can skip the frontend.
How to check. Send requests straight to the API with wrong types, empty fields and very long strings.
How to fix. Validate on the server with a schema library such as Zod or your framework's validator, and reject anything outside the schema.
6. Injection
What it is. User input becomes part of a database query, a shell command or the page's HTML. SQL injection and cross-site scripting (XSS) are the classic forms, and XSS is exactly where Veracode saw models fail most.
How to check. Search the code for queries built with string concatenation and for dangerouslySetInnerHTML or v-html on user content.
How to fix. Use parameterized queries or the ORM, and escape or sanitize anything rendered as HTML.
7. Insecure file uploads
What it is. Avatar or document uploads accept any file type and size, keep the user's file name and store files in a public bucket.
How to check. Try uploading an .html or .svg file with a script inside, then open its public URL. Check whether another user's files are reachable by guessing the path.
How to fix. Follow the OWASP File Upload Cheat Sheet: allow only the extensions you need, check the real file type, rename files on the server, cap the size and keep private files in a private bucket with access policies.
8. No rate limiting
What it is. Sign-in, password reset and AI features accept unlimited requests. That invites password guessing, and every call to a paid API such as an LLM or SMS provider is billed to you. OWASP lists missing limits on paid third-party services as a cause of outages and surprise costs (OWASP API4:2023).
How to check. Send 100 sign-in or AI requests in a minute from a script and see whether any are refused.
How to fix. Add per-user and per-IP limits on sign-in, reset and every endpoint that costs money, and set spending caps in the provider dashboards.
9. Outdated dependencies
What it is. The AI picked package versions from its training data, some of them old, and nobody updates them. Software Supply Chain Failures is new in the 2025 OWASP list at third place.
How to check. Run npm audit or pnpm audit, and turn on Dependabot or Renovate in the repository.
How to fix. Update packages with known vulnerabilities first, remove unused ones and review new packages before adding them.
10. No logging or alerts
What it is. When something goes wrong, there is no record of who did what. OWASP calls this Security Logging and Alerting Failures: without logs, a breach can go unnoticed for months.
How to check. Ask: if a user's data leaked yesterday, could you tell which account read it and when?
How to fix. Log sign-ins, permission errors and changes to sensitive records, without logging passwords or tokens. Add error tracking and an alert on spikes in failed requests.
11. Personal data in AI prompts
What it is. The app's AI features send customer records, emails or documents to a language model, sometimes with other users' data in the same context. OWASP ranks Sensitive Information Disclosure second among LLM risks (OWASP LLM02:2025).
How to check. Read the prompts the app builds and list every field that goes into them. Check the AI provider's data retention terms.
How to fix. Send only the fields the task needs, mask identifiers where you can and apply the same access rules to retrieved data as to the rest of the app.
12. No backups
What it is. The database lives on a free or default plan with no tested restore. In July 2025, an AI agent on Replit reportedly deleted a production database during a code freeze; the agent then claimed a rollback was impossible, which delayed recovery (AI Incident Database).
How to check. Find out when the last backup ran, and restore it to a separate database.
How to fix. Turn on daily backups or point-in-time recovery, keep production separate from development, and do not give AI agents write access to production.
Security checklist before launch
Before you launch a vibe-coded app, confirm each item below. Rows are ordered by impact: anything unchecked in the first four rows is a reason to delay the launch.
| Area | Check | Done when |
|---|---|---|
| Data access | Users can only read and change their own records | Replaying a request with another user's ID fails |
| Database | RLS is on for every exposed table, with policies per action | A query with only the public key returns nothing private |
| Secrets in the browser | No secret keys in the JavaScript bundle | A search of the deployed bundle finds only publishable keys |
| Secrets in the repository | No keys in Git history | A secret scan of all commits is clean; old keys are rotated |
| Input | Server-side validation on every endpoint | Malformed requests get a 400 error, not a crash |
| Injection | No string-built queries or raw HTML from users | Code search finds none |
| Uploads | Type, size and name checked on the server | A script file upload is rejected |
| Abuse | Rate limits on sign-in, reset and paid APIs | A burst of 100 requests gets throttled |
| Dependencies | No known critical vulnerabilities | Audit is clean; automated updates are on |
| Monitoring | Security events logged, errors alerted | You get an alert when a test error is triggered |
| AI features | Prompts carry only the fields they need | Prompt review lists no unneeded personal data |
| Recovery | Backups run and restore | A test restore to a separate database works |
When to get a code audit
Get a code audit when the app holds data you would have to disclose if it leaked, or when you cannot run the checks above yourself. A few signals:
- Paying customers, health or financial data, or anything covered by privacy law
- An investor or enterprise customer has asked for a security review
- Two or more checklist rows are failing or unknown
- Nobody on the team can read the backend and database policies
An audit should give you a ranked list of findings and a plan, not a rewrite pitch. For a broader view of where AI-written code needs a human, see our piece on how good ChatGPT is at writing code. If the app has deeper problems than security, our software rescue team stabilizes inherited and unstable products.
How Join.To.IT can help
Join.To.IT reviews and fixes apps built with Lovable, Bolt, Cursor and Replit. A production readiness review costs $300–$800 and takes up to a week: we test the app as a customer and as an attacker, check every risk on this list and rank what we find by launch risk. You get the findings and a fixed estimate before any larger work starts. Then we close the gaps, from access rules and secrets to logging, backups and CI/CD. See AI MVP to production.
We run the same checks on our own systems. In October 2026, after critical patches for GitLab, Node.js and PHP, we found missing security patches in our GitLab, a vulnerable Node.js inside our team chat's vendor image and end-of-life PHP versions on one server. We applied the GitLab security patches with a backup before each step, rebuilt the chat image on a patched Node.js before the vendor shipped one and patched every PHP version. Chat downtime was under two minutes.
FAQ
Is vibe coding safe for production?
Vibe coding can be safe for production if the app goes through the same checks as any other code before launch. The tools speed up building, but they do not plan for attackers. Turn on database access rules, keep secrets on the server, validate input, add rate limits, logging and tested backups, and have someone who reads code review the result.
How do I audit a vibe-coded app?
Start with access: replay requests as a different user, query the database with only the public key and search the deployed JavaScript for secret keys. Then scan Git history for leaked keys, run a dependency audit, test uploads and rate limits, and confirm that backups restore. The checklist in this article covers each step and what a pass looks like.
What are the most common security issues in AI-generated code?
The most common issues are missing authorization checks, database tables without access rules, secret keys exposed in the browser and missing input validation. Veracode's 2025 study found security flaws in 45% of its AI-generated test cases, with cross-site scripting and log injection among the most frequent failures. Outdated dependencies and missing logs are close behind.
Can you fix an app built with Bolt or Lovable?
Yes. Most apps built with Bolt or Lovable can be fixed without a rewrite: the screens and flows usually stay, while access rules, secrets handling and server-side logic get reworked. Export the code to a Git repository first, then run a readiness review to see what can stay. A rebuild is needed only when the data model itself is unsound.
