Vibe Coding's Next Test: Proving Your Database Is Locked

We think the next phase of vibe coding belongs to the people who can prove their app's database is locked. By the end of 2027, we expect anyone running an AI-built app that holds customer data to be asked for that proof, first by the platforms it runs on and then by the bigger companies it sells to.

The evidence arrived on October 1, when security firm UpGuard published a count of 16,326 Supabase databases that would hand table data to anyone who asked, including a valet company's list of more than 100,000 customers with phone numbers and about 78,000 license plates. UpGuard says the common thread is apps built by AI coding agents for owners who didn't know how their databases were set up. Vibe coding gets a demo working, and customer data needs the unglamorous parts done right.

TL;DR

• Our view: by the end of 2027, platforms and big customers will expect proof that an AI-built app's database is locked, and owners who check now will be ready.
• UpGuard found 16,326 Supabase databases with tables anyone could read among about 300,000 sites using Supabase, and more than half showed signs of personal data.
• Until Supabase's Security Advisor and a second-account test say otherwise, treat the customer data in an AI-built app as exposed.

Key fact: UpGuard counted 16,326 Supabase databases exposing readable tables among about 300,000 domains it found using Supabase.

What did UpGuard find?

UpGuard's researchers spotted Supabase in the public code of about 300,000 domains, then checked which databases would return data to an outsider, and 16,326 did.

UpGuard judged what each database held from its table layouts and didn't read every row. More than half showed signs of personal data, and a smaller share held passwords or login tokens. One relocation and immigration service had nearly 5,000 user records, and 884 of them stored a password in plain text. UpGuard notified owners where the exposure was significant, and the report doesn't say whether anyone else found these databases first.

Why do vibe-coded apps leave the database open?

We build on Supabase ourselves, and its design is sound. A Supabase app ships a public key to the browser, and Supabase's API keys guide calls that safe because the key only reaches what row-level security allows. The secret key skips those rules, so it has to stay on a server.

Row-level security is the lock: policies that work like a filter on every query, as Supabase's row-level security guide explains. Tables made in Supabase's dashboard get it automatically. Tables created in code need it switched on by hand, and UpGuard notes that's how coding agents create them.

The second failure looks like a lock. A policy exists, but it lets any signed-in user read every row. Supabase's Advisors docs show that pattern and name leftover placeholder rules as a common cause. If anyone can sign up for your app, a rule like that protects nothing.

What did Supabase say?

Supabase's chief information security officer, Bil Harmer, told TechCrunch for its September 25 story that the company hadn't seen the research. He said its projects start out secure and that "customers control how their own projects are configured." We agree with that second point, and it's why the job lands on you.

Supabase's 2025 security retro says dashboard-made tables get row-level security automatically and owners get email alerts about tables without it. Its changelog sets an October 30 change: on every existing project, new tables will stay hidden from the Data API, the layer your app's code calls, until someone grants access. Existing tables keep their current access. Don't wait for October 30, because it won't close a table that's already open.

What should you ask whoever built your app?

Ask for plain answers:

• Is row-level security on for every table, and what can someone read without signing in?
• What can a signed-in customer see that belongs to someone else?
• Where does the secret key live? Older projects call it the service_role key.
• Who owns the Supabase account, and who gets its security emails?

Supabase said in January that it emails organization owners a weekly summary of security findings. If your builder owns the account, those emails land in the builder's inbox. We'd put the account in your name and give the builder access.

How do you check your own app this week?

1. Run the Security Advisor. In your project's Supabase dashboard, open Advisors and choose Security Advisor. Fix errors and warnings first, starting with any table without row-level security and any rule flagged for unrestricted access. Rerun it after each fix, and don't dismiss a finding until someone can explain why it's safe.
2. Keep the secret key out of the browser. On your live site, open the browser's developer tools and search the loaded files for sb_secret_. It should never appear. The variable that holds the key can't start with a browser prefix like NEXT_PUBLIC_, or the build ships it to every visitor. If a key turns up, have your developer move it to the server, then replace it under Settings > API Keys.
3. Test with a second account. Make two test accounts on your live app. As the first, add something private, like an order or a message. Sign in as the second and confirm you can't find it.
4. Make that test permanent. A screen can hide data the database still sends, so have your builder repeat the check against the database as an automated test, which Supabase's row-level security guide walks through.

If an AI assistant offers to write your policies, let it draft them, and let the tests in steps 3 and 4 decide whether they work.

Where is this headed?

These are our predictions, and each rests on what UpGuard and Supabase have published.

• Our bet: a year from now, most of the 16,326 databases will still be open. The October 30 change leaves existing tables alone, and UpGuard says the people behind these sites don't understand their database setup.
• We think Supabase will switch on row-level security for every new table by the end of 2027, however it's created. Each change so far has moved the default toward closed, and UpGuard argues it's time to rebalance, as Amazon's S3 storage and GitHub did after their own waves of leaks.
• We expect AI app builders to block launches over critical database findings by the end of 2027. Supabase already serves its advisor checks to AI agents, down to a daily security monitor, and its changelog asks AI coding tools to build its access steps into how they create tables.
• We think big customers' vendor questionnaires will ask who checked your database rules by the end of 2027. UpGuard sells vendor-risk tools, and its report flags supply-chain risk: industrial-goods sellers, the sites most likely to handle corporate clients' data, showed high exposure risk, and the valet database held 4,560 email addresses at outside employers, including universities and Fortune 500 companies.

Should you stop vibe coding?

No. Keep building with AI, because it's the fastest way we know to put an idea in front of customers, and hand the database rules to a person who'll test them. If your app is already live with an open table, we'd fix it in place before rebuilding, since the fix lives in the database's rules. Our guide to AI-built websites covers the other places these builds break before launch.

If you'd rather not run these checks alone, we fix and launch AI-built apps.