Over 16,000 Supabase Databases Expose PII, Passwords and Auth Tokens: UpGuard Points to Missing Row-Level Security in AI-Built Apps
Over 16,000 Supabase Databases Expose PII, Passwords and Auth Tokens: UpGuard Points to Missing Row-Level Security in AI-Built Apps
Researchers at cyber risk management company UpGuard have found more than 16,000 misconfigured Supabase databases exposing readable tables containing personally identifiable information, passwords or authentication tokens. Supabase is an open-source development platform built around PostgreSQL that gives developers a ready-made backend — database, authentication and storage APIs — for building apps and websites faster, and it has become especially popular with AI-assisted development: UpGuard notes that AI-assisted development now accounts for more than 60% of newly created databases. The researchers analyzed a dataset of roughly 300,000 domains showing signs of using Supabase, checking for accessible data. In more than half of the exposed databases they found PII, with a smaller subset containing passwords and authentication tokens, and — based on the analysis of table schemas — a very small set appears to include credit card data.
The findings are concrete rather than statistical. A U.S. valet service exposed more than 100,000 customer records including contact details, license plates and visit history. A Canadian immigration service exposed nearly 5,000 user records — including 884 plaintext passwords. An India-based adult creator platform leaked sensitive identity data, payment accounts and over 100,000 private messages. A Philippines-based OTP service exposed data on more than 2,000 users and 100,000 SMS messages, some apparently unrelated person-to-person conversations. An African government consulate exposed records belonging to 25,000 people, including addresses and emergency housing locations.
UpGuard attributes the exposure to poor application security configuration — missing or ineffective row-level security (RLS) policies and misuse of public keys. The pattern is invariant to business type, in their words, because "the humans, who know what kind of business they are advertising, do not understand their database's configuration... The common thread is that these sites are created by AI coding agents and the humans are unaware of the configuration." The researchers stress the scans do not establish that every affected site was AI-built. UpGuard notified owners when its deeper analysis identified significant exposure, and Supabase users are encouraged to review the platform's security documentation, including its advisors and API security guide.
What Should You Do?
- If you ship on Supabase, check your RLS today: an accessible
userstable or any readable schema with PII means the public API key plus missing row-level security is publishing your data. - Audit what AI built: treat every AI-generated backend as unreviewed code — enumerate tables, check that the anon key cannot read sensitive columns, and verify that service-role keys never reached the client bundle.
- Encrypt or hash at rest by design: 884 plaintext passwords in one immigration-service database is an architecture failure, not a configuration slip.
- Watch for exposure of others' data: the OTP service leaked unrelated person-to-person SMS traffic — scope reviews to what your app stores, not just what it serves.
The WAF Angle
Nothing here is a Supabase vulnerability, and no attack traffic exists for a WAF to catch — the data is served by the platform's own public API, exactly as designed, to anyone holding the anon key that ships in every client. That is the uncomfortable part for edge-focused teams: the traditional perimeter question "is this request malicious?" never comes up, because the requests are perfectly legitimate API reads against a database that should never have been public. Supabase exposure sits in the same blind class as storage-bucket misconfigurations — your WAF sees normal traffic to a trusted domain, while the data model itself is the breach. The defense is database-side: enforce row-level security policies so the anon key can read nothing by default, alert on volume anomalies from the public API (mass reads of user tables are detectable even when authorized), and add "no PII behind a public key" to your AI-coding-agent review checklist. Sixty percent of new databases being AI-generated means this class of silent exposure is growing at machine speed — and the first scan that finds it should be yours, not UpGuard's.
