Your Supabase Is Public

Summary

I was chatting with a close friend of mine and he sent me a link to his new SaaS that he's developing. Of course when a friend sends me their new project my natural tendency is to try hack it. First simple step: inspecting, checking if there's something interesting. Voila, there is. A Supabase URL and anon key. What makes it particularly easy is when they're using Supabase. It's so common from my side that every time I get access to a Supabase anon key just from inspecting the website and doing a simple curl request to check the tables everything is always unprotected and I get access to the whole database. This is the third time I've discovered this and one of them was a seed stage startup 💀 With this endpoint you can fetch the OpenAPI schema to see what's exposed: curl -X GET \ 'https://your-project.supabase.co/rest/v1/?apikey=your-anon-key' \ -H "Accept: application/openapi+json"But the schema itself isn't that interesting. The interesting part is checking if they've created a users table and have an endpoint for it. And in my case it was something like this: curl -X GET \ 'https://your-project.supabase.co/rest/v1/users' \ -H "apikey: your-anon-key" \ -H "Authorization: Bearer your-anon-key"And if you're lucky (which happens way too often) this returns a nice JSON with all the users names, nicknames, emails, passwords hashes and whatever else they decided to store. I've never used Supabase for a production app but I think what's happening is people are creating additional public users tables and not setting proper RLS for them. The anon key is designed to be public but if you are not careful that anon key becomes a master key to your entire database. I'm not going to blame the vibe-coding wave entirely. Maybe I'll put the blame on Supabase instead? Maybe it can be simple if check if they create users table there should be a massive red warning popup explaining that everything in this table will be public unless RLS is enabled. And in the spirit of Lovable announc...