AI coding tools can build polished websites and customer portals in hours, but fast results can hide serious security gaps. New research involving Supabase databases shows how a working application can expose customer information when access controls are misconfigured. For small businesses using AI-assisted development, the warning is simple: a site can look professional, accept logins, and work exactly as expected while its database is more open than anyone realizes.
When a Working Site Still Leaks Data
Modern websites often depend on databases that hold names, email addresses, phone numbers, orders, messages, and account details. AI tools make those systems easier to create, even for owners with little development experience.
Picture a business owner asking AI to create a customer portal. The sign-up page works, orders load, and customer records save correctly. Everything looks finished. Yet none of that proves the database is limiting access the way it should.
TechCrunch reported that thousands of Supabase databases were exposing information to the public web, including names, addresses, phone numbers, passwords, and other sensitive data. The TechCrunch report on exposed Supabase data shows why a working website is not the same thing as a secure one.
What UpGuard Actually Found
UpGuard published its research on September 25, 2026, after gathering roughly 300,000 unique domains with signs of Supabase use. Researchers identified 16,326 databases exposing readable tables. More than half showed schema indicators associated with personally identifiable information, while smaller groups showed indicators of passwords or authentication tokens.
UpGuard did not claim every readable database contained confirmed sensitive records. Researchers used table schemas to estimate what might be exposed, then investigated selected cases where the metadata suggested meaningful risk.
Those checks found serious examples. A U.S. valet service exposed data tied to more than 100,000 customers, while an African government consulate database exposed personal information and physical addresses for about 25,000 people. The findings point to project configuration problems, not evidence that Supabase itself was breached. UpGuard’s original Supabase data exposure research explains the methodology and confirmed cases.
Why Vibe Coding Misses Security
“Vibe coding” usually means telling an AI coding assistant what you want and letting the tool create much of the application. For a small business, that can save time and money.
The problem starts when the prompt describes only what the app should do. “Build a portal where customers can create accounts and view orders” covers features, not database permissions. It does not say whether one customer can request another customer’s records or how powerful credentials should be stored.
OWASP’s Secure Coding with AI recommendations stress human review and accountability when AI tools write or test code. AI can help build the feature, but it should not be the only thing checking its own work.
How Row Level Security Protects Data
Row Level Security, often called RLS, lets a database control which records a person or role can read, add, change, or delete.
Imagine a table with 10,000 customer profiles. Customer A should see Customer A’s record, not Customer B’s. An employee may need broader access, while a signed-out visitor may need none. RLS can enforce those differences inside the database itself.
Supabase’s Row Level Security documentation explains that grants control whether a role can perform an action on a table, while RLS policies control which rows that action can affect. Supabase also states that Dashboard-created tables have RLS enabled by default, while tables created through SQL or another tool require RLS to be enabled explicitly. That matters when AI tools create database structures through code.
Public API Keys Are Not All Secret
The phrase “API key” sounds like another word for password, but some keys are meant to be visible. Supabase separates publishable keys from secret keys.
Publishable keys are designed for client-side environments such as websites and mobile apps. Users can discover them, so security cannot depend on keeping them hidden. Access still has to be controlled through database grants, RLS policies, and authentication.
Secret keys are different. Supabase states that secret keys use an elevated role that bypasses RLS, while legacy service-role keys carry similarly powerful access. Those credentials belong in trusted backend systems, not browser code or public repositories. Supabase’s API key security documentation explains the difference clearly. A visible publishable key is not automatically a leak, while an exposed secret key can create a serious security problem.
A Login Page Is Only One Layer
A working login screen feels secure, but authentication answers only one question: who is this person? Authorization answers another: what should this person be allowed to see or do?
A site can identify Customer A correctly and still let that account request Customer B’s information if authorization rules are too broad. Someone may also interact with an exposed API directly.
OWASP’s authorization security recommendations emphasize least privilege, deny-by-default rules, and checking permissions on requests. Testing should cover signed-out visitors, customers, staff, and administrators, including attempts to reach another user’s records. A login page helps, but it is only one layer of access control.
Checks Before Customer Data Goes In
An AI-assisted application should be tested before it collects real customer information, especially personal details, private messages, account information, or internal records.
A practical pre-launch review should include:
- Confirm that RLS is enabled wherever public-facing database access requires it.
- Review permissions separately for anonymous users, customers, employees, and administrators.
- Keep secret and service-role credentials out of browser code and public repositories.
- Test the application while signed out and while using different account types.
- Review new tables, API endpoints, migrations, integrations, and AI-generated features.
- Store only the customer information the business actually needs.
Supabase’s documentation on securing the Data API recommends using database grants together with RLS policies for exposed objects. Those controls handle different parts of the same problem. Data a business never stores also cannot be exposed later through a database mistake.
What Businesses Should Do Before Launch
Small businesses do not need an enterprise security department to use AI-built software. They do need someone who understands what the application connects to and how to check it before customers use it.
Start by identifying the database, tables holding customer information, API keys in use, and roles that can access each type of data. If nobody can explain those pieces because “the AI built it,” the project needs more review.
Then separate building from verification. Have a qualified developer or security professional review access policies, exposed endpoints, credentials, and account roles. Supabase’s production security checklist recommends reviewing database security issues and confirming RLS is enabled with appropriate policies before production.
Three tests are especially useful:
- Fill the application with fake records before importing real customer data.
- Test it while signed out and while using accounts with different permission levels.
- Stop deployment if any user can reach information or actions that role should not have.
Repeat those checks when major features, integrations, account types, or database tables change. Make review part of each release.
JENI® as Part of Layered Security
Database security is only one piece of small-business cybersecurity. Website permissions, cloud services, employee accounts, endpoints, backups, updates, and computer maintenance all matter.
JENI® focuses on local computer maintenance and system upkeep rather than configuring cloud databases or securing Supabase projects. Endpoint maintenance cannot replace application security review, just as a secure database cannot replace responsible maintenance of the computers used to access it.
A layered approach works better. Businesses should know what each tool protects, what it does not protect, and where another control or review is still needed.
Common Questions About AI Security
Is Supabase itself insecure?
The September 2026 research does not show that Supabase itself was breached. The reported exposures centered on project configurations and access controls that allowed data to be read more broadly than intended.
Are AI-built websites unsafe by default?
No. AI-assisted websites can be built securely, but working code does not prove that permissions, credentials, and database access are configured correctly.
What is Row Level Security?
Row Level Security limits which individual records a user or role can access or change. In a customer portal, it can help keep one customer from reaching another customer’s records.
Is a public API key a data leak?
Not necessarily. Supabase publishable keys are designed for environments where users can discover them, but the database still needs properly configured grants and RLS policies to control what they can reach.
Should small businesses avoid vibe coding?
Not necessarily. AI coding can make development faster and more accessible, but its security controls should be independently reviewed before the application handles real customer or company information.
AI Speed Still Needs a Security Check
The larger lesson goes beyond Supabase. AI gives small businesses development tools that once required bigger teams and budgets, but more people can also deploy software without deep experience in database permissions or application security.
The NIST Secure Software Development Framework recommends building secure development practices into the software life cycle rather than treating security as something added after release. That principle fits AI-assisted development because fast creation can make it tempting to move from prototype to production too quickly.
A polished website, successful login, and working checkout prove that the application functions. They do not prove customer information is private. Before real data enters an AI-built system, confirm who can access it, how permissions are enforced, where powerful credentials are stored, and what happens when someone requests information they should not receive. AI can make the build faster. The security still has to be checked.
Related Articles
AI Coding With Natural-Language Tools
See how natural-language coding tools turn ideas into working apps, and why AI-generated software still needs careful review before real-world use.
Website Security Basics for Small Businesses
Learn the website security basics that help protect customer accounts, business data, online services, and public-facing systems from common security risks.
How Public Repositories Can Expose Secrets
Learn how public code repositories can expose API keys and other credentials, why those leaks matter, and what businesses should check before publishing code.
Cloud Security for Small Businesses
Explore practical cloud security steps that can reduce data exposure, tighten access controls, and better protect information stored in online services.
