I scanned 100 random Supabase projects. 22% leak user data anonymously

Developers, do you love Supabase as much as marketers do? Turns out many love it so much they forget to lock the door. One brave soul scanned 100 random Supabase projects and found that 22% allow anonymous reading of user data. It's like leaving your apartment keys under the mat — except the mat is virtual and the apartment is a database.

The researcher (let's call him White Hat without a cape) didn't use any superpowers. He just took public Supabase endpoints and checked if RLS (Row Level Security) policies were configured. Spoiler: 22 projects either had no RLS or it was configured "half-assed." As a result, anyone who knew the project URL could access data — from emails to plaintext passwords. And these weren't abandoned sandboxes: real apps with real users were among them.

Why does this happen? The reasons are as old as time: negligence, deadlines, hope that "it'll be fine," and of course the magic of "it's BaaS, it protects itself." Supabase provides convenient APIs out of the box, but security is the developer's responsibility. If you think your project is too small to be attacked — remember that scripts roam the web and don't ask about size.

How to fix it? First, enable RLS for all tables. Second, use service roles only on the server. Third, don't store secrets in client code. And yes, do an audit — better now than after a leak.

METABYTE studio comment: We've always said: "Trust, but verify." Supabase is a great tool, but even the coolest Swiss Army knife can cut your finger if you don't know which side to hold. Want your project to be not only fast but also secure? Order an audit from us — we'll find holes you didn't even know existed.