UpGuard found 16,326 Supabase databases whose tables answered queries from anyone holding the public key printed in the site's own JavaScript. Over half showed signs of personal data. What a missing access rule means for the files people upload.
Researchers at UpGuard have published a study of exposed Supabase databases at internet scale. Supabase is a hosted Postgres service widely used by web apps, and by apps built with AI coding agents in particular. UpGuard collected about 300,000 domains showing signs of Supabase use, asked each one for a table called "users", and found 16,326 databases exposing readable tables. Over half had indicators of personal information. A smaller share held passwords or authentication tokens, and a very small number held what looked like credit card data.
To confirm the tables held real records, UpGuard examined a handful of databases and notified the owners where it found significant exposure. An Indian adult content platform exposed 65,467 users, with fields for driver's licence details, passport details and PAN card numbers, plus over 100,000 private messages. A US valet service exposed more than 100,000 customers, about 78,000 of them with licence plate numbers. A consulate run by an African national government exposed 25,000 users with physical addresses, and a field recording which emergency housing location each person was staying in. A Canadian immigration and relocation coaching service exposed nearly 5,000 records; 884 of them included a password stored in plain text.
UpGuard also notes that the problem is global. The same misconfigurations appeared in every region at the same time. Severity varied: UpGuard says European data protection law tends to push better practice, while developing regions tend to see more leaks.
A Supabase app's front end talks to the database directly, using a key embedded in the page. Supabase's documentation describes this publishable key as safe to expose, because it "only reaches what Row Level Security allows." Row Level Security (RLS) is the set of per-table rules that decides which rows a given visitor may read or write. With RLS on and written correctly, the public key is harmless. With RLS off, the same key reads the whole table.
UpGuard lists three failure patterns: RLS not enabled, policies that exist but do not restrict enough, and public keys used as if they were secrets. Supabase now enables RLS by default for tables created in its Table Editor, but UpGuard points out that tables created programmatically through the API, which is how coding agents work with Supabase, do not get it by default. Its conclusion is that many of these sites were assembled by AI agents for owners who never looked at the database configuration.
The underlying issue predates AI tools. In each of these databases, privacy depended on a server-side rule that someone had to remember to write, and to write correctly, for every table. When the rule was missing, the server returned plaintext to anyone who asked. Nothing about the data itself resisted being read.
UpGuard compares Supabase to Amazon S3 and GitHub, two services whose permissive defaults led to years of leaks. The same pattern applies to file storage. A bucket, a shared folder or a document table is protected by an access policy, and a policy can be deleted, mis-scoped or never created. The more systems a team runs, the more of those rules exist, and each one is a place for a plaintext copy to leak.
Access rules decide who the server will answer. Encryption with keys the server never holds decides what the server has to give.
Many applications need the server to read their data. A valet booking system has to see the licence plate. Files are often different: an ID scan, a passport page or a signed contract usually has to reach specific people, and the server in between does not need to open it. For that kind of data, the file can be encrypted on the sender's device, with keys that stay on the endpoints. The server stores ciphertext.
Then a missing or wrong access rule leaks ciphertext. Some things remain visible: file sizes, timestamps and whatever metadata the service keeps. A compromised endpoint still exposes what that endpoint can read. Even so, the readable contents are no longer sitting in a table that one forgotten setting can open to the internet. Encryption is also one control among several. The Canadian service's 884 plain-text passwords needed hashing, which is a separate fix.
SpaceBox Lite is built on that model for sending files. Each file is encrypted on the sender's device using post-quantum ML-KEM-768 (NIST FIPS 203) key exchange and AES-256-GCM. Keys stay on the device, and our servers hold ciphertext only, so our own access controls are not the only thing standing between a file and a reader. Senders need no account and give us no personal data. Post-quantum key exchange is available in other products as well; the relevant property here is that the server storing the file has no key to open it.
Lite is free, with a 1 MB, 3-file tier and a free voucher at beta.i46.space that adds 100 MB and 100 files (email required). During the beta it is not available to residents of the EU or EEA. See Why SpaceBox for how it compares with conventional cloud storage.