Everyone Is Vibe Coding Their Business Website. Here's What's Getting Exposed.

Everyone Is Vibe Coding Their Business Website. Here's What's Getting Exposed.

The Moment That Woke the Industry Up

January 2026. A startup called Moltbook — a social network built almost entirely using AI tools — had 1.5 million API keys sitting in an exposed database. Not buried deep in some obscure backend. Accessible. Logged by anyone who knew where to look.

A month later, security researchers ran a systematic scan of websites built with Lovable, one of the most popular AI website builders of the past year. They found more than 170 databases with zero row-level security. Customer emails, form submissions, booking records, and in some cases sensitive personal information — sitting there, readable, on businesses that had no idea.

This isn't a hypothetical future risk. This is what happened over a handful of months.

The One That Made It Concrete: 18,697 Records, Including Kids

In February 2026, a security researcher examined a single real, live application built on Lovable. The app had been seen over 100,000 times on Lovable's own showcase. It looked professional. It functioned. People were using it.

The researcher found 16 security vulnerabilities. Six of them were critical.

The worst one: the authentication system was built backwards. Strangers could get in. Actual registered users were getting locked out. The database behind the app — containing 18,697 user records — was accessible to anyone who knew how to look. Those records included 4,538 student accounts from UC Berkeley and UC Davis.

Not a hypothetical. Not a stress test. A live application with real users whose information was sitting exposed, on a platform marketed to people who do not know how to code.

What Vibe Coding Actually Means

For anyone who hasn't been following the trend: vibe coding is the practice of building websites, apps, and digital products by describing what you want to an AI — Lovable, Bolt.new, Cursor, Wix AI, Squarespace AI — and having it write the code for you. No traditional development experience required.

The results are genuinely impressive. For prototypes, personal projects, landing pages, and early-stage products, it has changed what's possible for founders and small business owners with limited budgets — a question we've looked at head-on in how far AI can realistically take a business website.

The problem is not the tools. The problem is when real businesses — ones collecting real customer data, processing real transactions, or storing anything sensitive — launch these AI-built products without anyone with security experience ever reviewing them.

Why the Security Breaks the Way It Does

The Register's reporting on the Lovable app describes something specific about how that failure happened — and it matters, because it is not random. It is structural.

AI coding tools are trained to make things work. When you describe a login system, the AI builds a login system that functions: users can sign up, sign in, and access their account. What it does not automatically do is think through who else might be able to access those accounts, what happens if someone sends a malformed request, or whether the rules governing who can see which records are actually enforced at the database level.

The authentication was backwards because the AI built what was described, not what was implied. No one asked: what should happen when someone who is not logged in tries to read another user's data? Without that question being asked and answered explicitly, the AI left the door open.

What "No Row-Level Security" Actually Means

The Lovable scan found something specific across those 170+ databases: no row-level security. In plain English, here is what that means.

Imagine your website has a customer database. Row-level security means each user can only access their own records — their own bookings, their own account history, their own payment info. Without it, the structure is there but the gates are not locked. Someone who understands how to query a database can access records that do not belong to them.

For a service business, that might be intake forms with client names and contact details. For a health-adjacent practice, it gets significantly more serious. For anyone storing payment methods or account credentials, the exposure is direct.

Proofpoint also reported tens of thousands of malicious URLs built with Lovable being used in phishing campaigns in early 2026. The AI-generated sites looked legitimate — professional design, real domains, functional forms — because they were built with the same tools used to build legitimate businesses. That is the other edge of this sword.

The Statistic Worth Sitting With

Veracode's 2025 GenAI Code Security report found that 45% of AI-generated code samples failed security testing — introducing OWASP Top 10 vulnerabilities directly into the code. The OWASP Top 10 is not an exotic list. It is the standard catalogue of the most common, best-documented web vulnerabilities in existence; it is the first thing any security audit checks for. Nearly half the samples fell over on it.

That is not a knock on AI tools — they are improving rapidly, and Lovable and others have been adding security checks and better defaults as these incidents come to light. It is a reflection of the gap between "this looks like it works" and "this is safe for real-world use." And a tool cannot check for problems it is not aware of in your specific configuration, your specific integrations, your specific business context.

Who Is Actually at Risk

Not everyone. A simple portfolio site or a landing page that sends form submissions to your email has a small risk surface.

The risk scales directly with what your site does. You should pay close attention if your site:

• Collects personal information through any form
• Has user accounts or login functionality
• Processes bookings, payments, or appointments
• Stores customer history or contact records
• Connects to any third-party API using credentials or keys

If any of those describe your site and it was built primarily through an AI tool without a dedicated security review, it is worth taking a serious look.

Why This Is a Business Problem, Not a Tech Problem

The Lovable story is easy to read as someone else's problem. A tech platform. Students at a university. Not your customer base, not your industry.

But here is the overlap: the same tools that built that app are being used right now by freelancers, web designers, and marketing agencies to build small business websites. Quickly and affordably, which is exactly what the pitch promises. A restaurant's online ordering system. A law firm's client intake form. A contractor's booking page. A medical practice's appointment scheduler.

Every one of those collects real information from real people. Most of them have never had a security review of any kind.

These are not technical questions that only developers care about. They are business liability questions. A data exposure involving your customers' information — even a small one, even one you did not cause and did not know about — can damage trust in a way that takes years to repair.

A Self-Audit You Can Run Today

You do not need to understand the code to ask the right questions. Run through these honestly.

Who built your site, and how? If it was primarily AI-generated, ask directly: did a developer review it before launch? Not "did it work" — did anyone check specifically for access control and data exposure? Some builders handle the security side better than others, and that difference shows up in what you inherit.

What does your site collect, and where does that data go? Walk through your own contact forms, booking systems, and login pages. For each one: if a stranger submitted this, where does the data land — a database, a spreadsheet, an inbox? Who has access to that destination?

Are you using a third-party platform or a custom backend? Booking tools like Calendly, payment processors like Stripe, and form tools like Typeform have their own security teams and compliance programs. Custom-built backends — even AI-built ones — do not come with that protection automatically.

Are any API keys sitting in your frontend code? AI tools sometimes embed keys where they are visible to anyone who inspects the page source.

Has your site changed significantly in the last year? New integrations, new features, new forms, a new developer — any of these can introduce vulnerabilities that did not exist at the original build.

Do you know what happens if something goes wrong? Who do you call? Does anyone have a backup? Knowing the answer before something happens is a very different position than finding out during one.

If you cannot answer most of these, that is the useful information. It tells you where to focus.

The Uncomfortable Pattern

Here is what the businesses that were not exposed in these incidents have in common: they did not skip the security conversation before launch.

That sounds obvious. But it is a completely different conversation than most web projects have. It is not about whether the site looks right or whether the contact form sends correctly. It is about who can access what, what happens if a credential leaks, how the backup plan works, and whether any part of what you are collecting triggers compliance requirements for your industry.

Those are not complicated questions. They are just not questions AI tools ask automatically — because the tool is building what you describe, not auditing what you haven't thought of yet. And in the typical small-business web project, especially a cheap freelance build, the engagement ends when the site goes live and looks correct. The security layer, if it comes up at all, gets treated as optional or as something to revisit later.

Later is when the researcher finds the exposure. Later is when a customer calls to say their information appeared somewhere it should not have. Later is when it becomes public.

The Sitora Take

AI tools are not the enemy. They have made building on the web more accessible than it has ever been, and that is genuinely good for small businesses. But accessibility and security are two separate things — and for a business collecting real data from real customers, both matter.

Most small business owners would not hand a stranger the keys to a filing cabinet containing every client's contact information. That is effectively what an unsecured database behind a website amounts to. The difference is that the filing cabinet is visible and the database is not — so the risk stays invisible until it isn't.

The businesses that are going to do well in this next phase are not the ones avoiding AI tools. They are the ones who pair those tools with someone who knows where the gaps are and closes them before launch, not after.

👉 Get a security and architecture review or book a call with Sitora