Vibe coding has made it possible for a business owner to describe an app in ordinary language and have an AI assemble the database, interface, authentication, and logic in hours. That speed is extraordinary. It also creates a dangerous psychological shortcut: if the app works on the screen, people assume the plumbing behind it must be correct. New research from UpGuard is a brutal reminder that functional and secure are two different adjectives.
What UpGuard Found
On September 25, security company UpGuard published research on Sublease-backed applications. Across roughly 300,000 identified domains, the researchers found 16,326 databases exposing readable tables. More than half of those exposed databases contained indicators of personal information, while smaller numbers included password or authentication-token fields and some appeared to involve payment-related data. The problem did not require a cinematic hack; in many cases, database access controls simply had not been configured correctly.
The Important Detail Is How the Tables Were Created
Supabase uses PostgreSQL Row Level Security, usually shortened to RLS, to control which users can read or change which rows. UpGuard highlighted a dangerous difference between tables created through safer dashboard workflows and tables created programmatically through SQL, migrations, APIs, or coding tools. When an AI agent writes the schema, it may create a perfectly functional table without also enabling the policies needed to stop unauthorized reads. The app works beautifully right up until somebody asks the database a question it should never answer.
This Is Not an Argument Against Supabase or AI Coding
Supabase is widely used because it makes powerful database and authentication features accessible, and AI coding tools are popular because they make software creation faster. The lesson is about shared responsibility. A platform can provide security controls while a developer—or an agent acting like a developer—configures them incorrectly. Every generated application should be reviewed as if it were written by a very fast junior programmer who confidently finished the assignment but may not know what it forgot.
Small Businesses Have More to Lose Than They Think
A little scheduling app can contain names, phone numbers, addresses, notes, and appointment history. A quote form can contain property details. An internal dashboard can contain employee records. A membership app can contain payment identifiers and account information. The fact that the company only has five employees does not make leaked customer data harmless. Small organizations often have less legal, security, and public-relations capacity to recover when something goes wrong.
Security Review Needs to Be Part of the Build Prompt
When using an AI builder, explicitly require authentication rules, authorization checks, Row Level Security where applicable, input validation, rate limiting, secure secret storage, dependency review, logging, backups, and tests for what an unauthenticated user can access. Then verify those controls independently rather than trusting the generated explanation. Ask the system to attack its own assumptions, but also use platform security advisors, code review, and outside testing for anything handling sensitive data.
Do Not Store Secrets Where the Browser Can Read Them
One recurring mistake in AI-generated applications is putting privileged keys, service-role credentials, or private tokens into front-end code because doing so makes the first demo work. Anything delivered to the browser should be treated as public. Server-only secrets belong on the server, and database policies should assume attackers can see the public project URL and ordinary client credentials. Security that depends on nobody inspecting JavaScript is not security.
Bottom Line
The most frightening part of UpGuard’s 16,326 exposed databases is how ordinary the failure is. No zero-day exploit is required when an application simply forgets to lock the door. AI coding can be an incredible accelerator for small businesses, but speed does not transfer accountability to the model. Before a generated app stores real customer information, test what a stranger can read, what an ordinary user can change, and whether every table has the access rules you intended. “It works” is the beginning of the review, not the end.
