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 announcing their $330 million Series B and knowing they also use Supabase. I'm starting to wonder what percentage of users actually make this mistake. With over 100,000 projects being created daily on platforms like Lovable, how many of those have exposed databases?

Again, you can take the stance that this is a skill issue on the users part but I'm not sure about that. You can design a system in a way that prevents this type of stuff from happening.

As an example Pocketbase handles this much better. It has a default _pb_users_auth_ collection that you can easily extend with new fields, and most importantly, it has default proper access control checks like id = @request.auth.id already configured. You literally have to go out of your way to make it insecure.

So I guess here the place where I need to say something smart or LLM generated conclusion - but I don't have. Merry Christmas! 🎄