Vibe Coding Security Risks: Why AI-Built Apps Leak Custom...

Something genuinely new happened to software in the last two years: the person building the product often is not a developer at all. A founder describes an app in plain English, an AI agent writes it, and a payment page goes live the same afternoon. The build problem is largely solved. The security problem is not—and the gap between the two is now producing a steady stream of breaches involving real customer data.

The Builder Is No Longer a Developer

"Vibe coding"—describing what you want and accepting what the model produces—has moved from a novelty to a business practice. Platforms in this category now serve millions of users, and a meaningful share of them are building things that take payments, store identity documents, and hold customer records. Wiz Research found that roughly one in five organizations building on vibe-coding platforms had inadvertently exposed themselves to risk.

None of this is an argument against AI-assisted development. We use these tools ourselves. It is an argument that the skill AI has automated—writing code that works—was never the skill that kept software safe.

AI Writes Functional Code. It Does Not Write Secure Code.

This is measurable, and it has been measured carefully. Veracode's 2026 GenAI Code Security Report found an average security pass rate of just 56% across the models tested—effectively unchanged from 55% in the previous edition. Put plainly: roughly 44% of AI code-generation tasks introduced a risky security vulnerability, even as the same models got dramatically better at producing code that runs.

The failures cluster. Models handled SQL injection well (83% pass rate) and cryptographic algorithm selection well (87%), but collapsed on cross-site scripting (15%) and log injection (12%). These are not exotic attacks. They are decades-old entries in the OWASP Top 10, and they are precisely the categories a non-technical builder has no reason to know exist.

"Functional correctness and security correctness are different problems. An AI model optimised for the first will confidently ship failures in the second."

The Confidence Gap Is the Real Danger

Stanford researchers Neil Perry, Megha Srivastava, Deepak Kumar, and Dan Boneh published a controlled study asking whether people write more insecure code with AI assistants. They found two things. Participants with access to an AI assistant wrote significantly less secure code. And those same participants were more likely to believe their code was secure.

That second finding is the one that should worry business owners. An inexperienced builder who feels uncertain will ask for a review. An inexperienced builder who feels confident will launch. The study also found that participants who trusted the AI less and iterated harder on their prompts produced code with fewer vulnerabilities—scepticism, it turns out, is a security control.

What This Looks Like in Production

The incident record has moved well past the theoretical.

CVE-2025-48757: Unauthenticated Reads and Writes Across Hundreds of Apps

Insufficient Row-Level Security policies in Lovable-generated sites allowed remote, unauthenticated attackers to read from and write to arbitrary database tables. It carries a CVSS score of 9.3, required no credentials and no user interaction, and exposed more than 170 applications. The generated apps enforced access control in the browser—which any attacker can simply bypass by talking to the database endpoint directly.

The 2026 Lovable Disclosure

A broken object-level authorization flaw let anyone with a free account reach other users' projects, source code, and database credentials in as few as five API calls. It was reported on 3 March 2026 and disclosed publicly on 20 April 2026, after 48 days. Exposed material included hardcoded Supabase credentials and personal data—names, job titles, LinkedIn profiles, Stripe customer IDs—belonging to people at organisations including Accenture Denmark, Copenhagen Business School, Nvidia, Microsoft, Uber, and Spotify.

Moltbook: Breached Within Days of Launch

The vibe-coded social network Moltbook exposed roughly 1.5 million API authentication tokens and 35,000 email addresses through a misconfigured Supabase database with no row-level security—within days of going live.

The Base Rate

In June 2026, Symbiotic Security scanned 1,072 live vibe-coded applications. 98% had at least one security flaw; only 26 sites were clean. Sixteen percent carried at least one critical flaw, and 172 sites permitted data deletion and modification with no authentication whatsoever. This is not a story about a few careless builders. It is close to the default outcome.

The Same Four Mistakes, Over and Over

What is striking about these incidents is how little variety there is in them. Wiz's analysis identified four recurring categories, and almost every public failure fits one of them:

Authentication enforced in the browser. Password checks living in JavaScript, or session state kept in LocalStorage, with no server-side validation. The code looks like a login. It functions as a suggestion.

Secrets shipped to the client. API keys for payment processors, email services, and model providers hardcoded into client-side bundles, readable by anyone who opens developer tools.

Database access left open. Row-Level Security disabled or written permissively, so the anonymous public key—which is supposed to be safe to expose—can read and write every row in the table.

Internal tools deployed publicly. Admin dashboards, staging environments, and back-office screens pushed live with no authentication in front of them, discoverable through certificate transparency logs and ordinary crawling.

An experienced engineer catches all four in a code review. An AI agent optimising for "make the feature work" does not raise them, because from its perspective nothing is broken.

This Is a Legal Exposure, Not Just a Technical One

For businesses operating in Uganda, the Data Protection and Privacy Act, 2019 applies regardless of who—or what—wrote the code. Any organisation collecting or processing personal data must register with the Personal Data Protection Office, and penalties for serious breaches reach up to 2% of annual gross turnover, with custodial sentences available for certain offences. Businesses serving EU or UK customers face GDPR obligations on top of that.

No regulator anywhere accepts "the AI built it" as a defence. The data controller is the business. Liability follows the customer relationship, not the toolchain.

How to Ship AI-Assisted Software Safely

The answer is not to stop using AI. It is to restore the review step that AI removed.

1. Decide What You Are Protecting Before You Prompt

Write down, in one page, what data the application will hold, who is allowed to see each category, and what happens if it leaks. This is the input a model cannot infer from "build me a booking app," and it is the document a security reviewer needs.

2. Treat Every Client-Side Control as Cosmetic

Anything enforced in the browser can be bypassed. Authentication, authorisation, pricing, quotas, and role checks belong on the server or in database policy. Ask your AI assistant explicitly where each check is enforced—and verify the answer rather than accepting it.

3. Default Your Database to Deny

Enable Row-Level Security on every table, start from a policy that permits nothing, and add narrowly scoped permissions as features require them. Given how many of the incidents above trace back to this single setting, it is the highest-leverage twenty minutes available to any team using a hosted database.

4. Get Secrets Out of the Bundle

Third-party API keys belong in server-side environment variables or a secrets manager, accessed through a backend proxy. If a key has ever been committed to a repository or shipped to a browser, rotate it—it should be treated as public.

5. Have Someone Qualified Review It Before Launch

A professional security review before you accept your first real customer is cheaper than breach notification, regulatory response, and rebuilding trust afterwards. Combine automated scanning with human review: scanners catch known patterns, people catch broken business logic.

6. Plan for the Incident You Hope Not to Have

Enable audit logging, know who is called at 2am, and write the notification procedure while you are calm. The Lovable response—denial, then blame-shifting, then partial apology—is a useful case study in how much reputational damage the hours after a disclosure can cause.

Conclusion

AI has removed the barrier to building software. It has not removed the consequences of building it badly, and it has quietly removed the person who used to notice. The businesses that will do well with these tools are the ones that treat generated code exactly as they would treat code from a fast, tireless, and entirely unsupervised junior developer: useful, welcome, and reviewed before it touches a customer.

If you have shipped something built this way and no one qualified has looked at it, the four checks above are where to start—and a security review is worth booking before you find out the hard way.

Vibe Coding Security Risks: Why AI-Built Apps Leak Customer Data