Is Your AI-Built Store's Database Publicly Exposed?

You shipped the store in a weekend. Lovable, Bolt, v0, Cursor, Replit — whatever tool you used, it worked. Products load, checkout runs, orders are coming in. Nobody on your team has ever pointed a REST client straight at your database to see what happens, because nobody thought to ask.

That question got answered for over a thousand stores in June 2026, and the answer wasn't good.

What a scan of 1,072 AI-built apps actually found

Security firm Symbiotic Security scanned 1,072 applications built on the most common AI coding platforms — Lovable, v0, Bolt.new, Replit, Windsurf, Tempo — all wired to Supabase as the backend. Ninety-eight percent had at least one security vulnerability. Sixteen percent had a critical one.

Broken down, the scan found 39 sites where the entire database was readable by anyone, no login required. 172 sites allowed unauthorized data deletion through the REST API. 172 more allowed unauthenticated record modification — meaning any visitor could edit rows in your production database. 308 sites exposed the Supabase anonymous key directly in client-side JavaScript, which is expected, but became dangerous the moment it was paired with the next finding: no policy restricting what that key could touch. Tables named payments, admin_users, and chat_messages turned up discoverable without authentication across multiple apps, with payment data specifically exposed on at least three of the scanned sites.

This is not a story about one careless developer. It is a story about a default.

The real problem is one setting, not one bug

Supabase runs on Postgres, and Postgres has a genuinely good security feature called Row-Level Security (RLS). Turned on and configured correctly, RLS means a database table can enforce, at the row level, exactly who is allowed to read or write which record — a customer can see their own orders, nobody can see anyone else's, and an anonymous visitor gets nothing. Turned off, or left with a default "allow all" policy while a team is "just testing," the same table is wide open to anyone who has the project's public API key, which is visible in your site's own JavaScript by design.

AI coding assistants are very good at wiring up a working checkout flow. They are inconsistent about writing the RLS policy that keeps that checkout flow's customer and payment data private, because that policy has no visible effect on whether the demo works. The store looks finished. It functions perfectly for the person building it. Whether it functions correctly for everyone else depends on a setting most builders never learn exists until someone tells them, or exploits it first.

This is not a handful of bad apps

Red Access published a separate report in May 2026 — covered by Axios, WIRED, and VentureBeat — that scanned across six continents and found over 380,000 publicly accessible vibe-coded web assets. More than 2,000 held sensitive corporate, operational, or personal data, many connected to production systems like CRMs and ERPs, and deployed, in the report's words, "without basic access controls, often granting admin access by default to anyone who reached the URL."

Read together, the two reports say the same thing from different angles: the gap isn't a specific mistake any one founder made. It's a category of gap the current generation of AI build tools reliably leaves open, on ecommerce stores as much as anywhere else — arguably more, because a store's database holds the two things attackers most want, customer PII and payment data, sitting behind the one control most AI-generated code skips.

What an actual fix looks like

Closing this gap is not a rewrite. It's an audit followed by a defined set of fixes: RLS policies written and tested per table, the service-role key moved off the client entirely and confined to server-side code, the anonymous key's permissions scoped down to only what a logged-out visitor should touch, CORS configuration checked, and every finding verified by actually attempting the exploit — not just reading a scanner's report and assuming the fix worked.

That verification step is the part most cleanup work skips, and it's the one MnT Future treats as non-negotiable. Our AI Cleanup Lab exists to demonstrate exactly this discipline: we built a deliberately flawed store, exploited it ourselves to confirm the vulnerabilities were real, then rebuilt with hardened infrastructure and re-tested every finding — seven security findings identified, two critical, five out of five live exploits closed and verified, measured before and after rather than assumed.

If your store was built fast and has never had its database access rules checked, the honest first step is finding out what's actually open — not guessing.

A five-minute check before you call anyone

You don't need a full audit to get a first signal. Open your site's browser dev tools, find the Supabase URL and anon key your own JavaScript ships to every visitor, and try a plain GET request against a table you'd expect to be private — orders, customers, whatever holds the data you'd least want public. If it returns rows instead of an empty array or a permissions error, you have the exact problem this scan found. That five-minute check won't tell you everything — CORS, service-role exposure, and write access all need a proper look — but it tells you fast whether you're in the 98% or the 2%.

Ready to know what's actually exposed on your store, rather than guess? MnT Future runs a free strategy session where we walk through your store's database access rules together and tell you plainly what needs fixing and what doesn't — no obligation, no upsell if the answer is "you're fine."

Do AI-built ecommerce stores expose customer data by default?

Often, yes. A June 2026 scan of 1,072 Supabase-backed apps found 98% had a security flaw, most commonly a missing Row-Level Security policy that leaves database tables — including payment and customer records — readable or writable by anyone with the site's public API key.