Are Vibe-Coded Apps Safe? 8 Security Holes to Check

Are vibe-coded apps safe?

Not by default: the large studies cited here all found serious security holes in a large share of the apps they examined ^[3][4][5]. The apps usually work. The problem is what they let strangers do.

A 2026 audit collected 9,041 open-source apps built with Claude Code and Lovable and examined 200 that were publicly deployed. It found 1,186 vulnerabilities, and 182 of the 200 apps (91.0%) had at least one ^[4]. Of those flaws, 65.77% were rated Critical or High, including 18.47% Critical ^[4].

The authors also tested whether better prompts and agent setups fix the problem. They reduced it but did not remove it, and the same task run three times could produce a secure result once and an insecure one the next time ^[4]. In other words, a clean result on one build says little about the next.

For the basics of the method itself, see the Pouyam guide Vibe Coding Explained: What It Is, How It Works and the Real Risks. For a first project, Vibe Coding for Beginners: How to Start Safely in 2026 gives a starting plan. This page goes one level deeper: the specific holes and how to test for each one.

What do security studies find in vibe-coded apps?

Four independent sources point to the same weak spot: data that the wrong person can read or change ^[1][3][4][5].

• Audit of 200 deployed apps (2026): broken access control was the largest category, with 339 of 1,186 flaws (28.58%), and it affected 64.00% of the apps. Injection affected 54.00% and authentication failures 51.50% ^[4].
• ACM CCS 2026 study: across 8,641 Lovable repositories with full history, 11.2% of database read rules were open to signed-out visitors and 61.2% of repositories had at least one such rule. A replay test confirmed the exposure in 353 of 400 sampled repositories ^[5].
• Escape (October 2025): a passive scan of more than 5,600 public apps built on platforms such as Lovable, Base44 and Create.xyz found more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of personal data, including medical records, IBANs (bank account identifiers), phone numbers and emails ^[3].
• CVE-2025-48757 (2025): a scan completed on 21 March 2025 found 303 database endpoints across 170 of 1,645 Lovable projects, about 10.3%, with inadequate row rules ^[1].

Escape stresses that its scan avoided anything destructive, so its counts are a lower bound; a deeper test would find more ^[3]. The same caution applies to every number here: these studies count what they could see from outside.

Why do AI tools build insecure apps?

Because the tools optimise for an app that works, and security rules depend on business details the prompt rarely spells out ^[4][11].

Code that runs is easy to check: the page loads, the button works. Who is allowed to see each record is a business decision, and if nobody writes it down, the tool has to guess. The 2026 audit traces the flaws to eight recurring failure modes, grouped into three limits of AI agents: memory, objectives and knowledge ^[4].

Broad tests of AI models show the same gap. Veracode's 2026 GenAI Code Security Report found that roughly 44% of AI code generation tasks introduced a security vulnerability in its tests ^[11]. A benchmark cited by AWS found that the best of 12 agent settings solved 57% of tasks correctly but only 11.8% both correctly and securely ^[10].

Many vibe-coded apps also run in a way that moves security to the database. The browser talks straight to a hosted database, so the database rules are the only thing standing between a visitor and every row ^[1][6]. When the rules are missing or too broad, anyone who knows the address can ask for everything.

Which 8 security holes should I check first?

Start with the holes that the studies find most often, ordered by how much damage they can do ^[1][3][4][5].

1. Open database rules: tables without row level security, or with rules that let any visitor read every row. This was the root of CVE-2025-48757 and of the ACM findings ^[1][5].
2. Broken access control: a signed-in user can open another user's record by changing an ID in the address or the request. It was the top category in the 2026 audit ^[4].
3. Secret keys in the browser: a Supabase secret or service_role key, a payment key or an AI provider key placed in front-end code. Escape found 400+ exposed secrets ^[3][6].
4. Missing or weak sign-in checks: private pages or API routes that answer without a session. Authentication failures hit 51.50% of audited apps ^[4].
5. Injection: user input reaching database queries or HTML without checks, found in 54.00% of audited apps ^[4].
6. Writable tables: rules that let visitors insert or change data, not just read it. In the CVE case, a request without a sign-in token inserted a record marked "paid" and skipped the payment step ^[1].
7. Leaky responses: APIs that return whole user records, emails or tokens when the page only needs a name. Escape counted 175 instances of exposed personal data ^[3].
8. Risky agent access: a coding agent that holds production credentials can do real damage; in July 2025 an agent deleted a live database during a code freeze ^[10].

Holes 1 to 4 cover most of what outsiders exploit, so test them before anything else.

How do I test my vibe-coded app for these holes?

Use the app the way an attacker would: as a stranger, as a second user and by reading what the browser receives ^[1][4][5]. None of these steps needs special tools.

1. Make two test accounts. Create a record with account A, copy its address or ID, sign in as account B and try to open, edit and delete it. If it works, access control is broken ^[4].
2. Repeat signed out. Open the same addresses in a private window with no session. In the CVE case, removing the sign-in header was enough to bypass every check ^[1].
3. Watch the network tab. In the browser's developer tools, look at each request the page makes and what comes back. Responses should hold only what that screen needs, never other users' emails or tokens ^[3].
4. Search the page code for keys. Look for strings starting with sb_secret_, the service_role label, or provider keys such as payment or AI keys. A publishable key is expected; a secret key is an emergency ^[6].
5. Check every table's rules. In the database dashboard, confirm row level security is switched on for every table and read each rule in plain terms: who can read, who can write ^[7].
6. Try bad input. Paste very long text, quotes and HTML tags into each form and see whether the app breaks or shows them as code ^[4].

Test only apps you own or have permission to test. Do not probe other people's apps without written permission.

How do I fix open Supabase rules and leaked keys?

Turn on row level security for every table, write narrow rules, keep secret keys on the server and replace any key that has leaked ^[6][7][8].

• Enable row level security everywhere. Supabase's guide says to enable it on every table in an exposed schema ^[7]. Once it is on, the public key reaches nothing until you add rules ^[7].
• Remove default grants. On projects that still grant them by default, a new public table starts with every privilege already granted to the signed-out (anon) and signed-in (authenticated) roles, and adding rules does not take those grants back ^[7]. Revoke them and grant back only what each role needs ^[7].
• Write rules per user. A rule for a private table should match the signed-in user's ID, not simply allow everyone who is logged in. Avoid rules that are always true on sensitive tables ^[2].
• Keep secret keys server-side. Supabase's publishable key is safe in the browser only because row rules limit it; secret and service_role keys bypass every rule and must stay in server code or secure environment settings ^[6].
• Rotate leaked keys. If a secret key ever reached the browser or a public code repository, replace it and retire the compromised one, as Supabase's key guide advises ^[6].

As of 15 November 2026, Supabase's documentation says it is deprecating the old anon and service_role keys by the end of 2026 in favour of publishable and secret keys ^[8]. The new secret keys return an error (HTTP 401) when used in a browser, though a leaked key can still be used from other tools ^[6][8]. Moving now is a good moment to review every key an app uses.

Do built-in security scanners catch everything?

No: platform scanners help, but several studies show they miss the rules that matter most ^[1][2][5].

In 2025, the researchers behind CVE-2025-48757 found that Lovable's scanner checked only whether a row rule existed, not whether it was correct ^[1]. Their advisory adds that Lovable's publish check flags tables without rules but does not show whether the rules are strict enough ^[2]. An open rule passes a check like that.

The ACM study makes the same point with numbers: a modest share of open rules, 6.3% across six tools, still left 56.9% of repositories with at least one exposed table, because one open rule is enough ^[5]. The authors released a free checker that flags such rules before code is committed ^[5].

Use scanners as a first filter, then do the two-account and signed-out tests yourself. The table below sums up the numbers.

Is it safe to use apps other people vibe coded?

Be careful with anything that asks for personal, health or payment data, because users cannot see how an app protects it ^[3][4]. Escape found medical records and IBANs (bank account identifiers) among the exposed data ^[3].

Some simple habits lower the risk. Use a unique password for each new app, so a leak in one does not open others; the Pouyam guide Password Managers Explained: How They Work and Whether They Are Safe covers how. Share the minimum data an app needs, and prefer payment pages run by known payment providers over forms inside the app.

Builders carry the main duty. If you publish an app that stores other people's data, run the checks above before launch and again after each big change, since a single new feature can reopen a closed hole ^[4][5].