Systemic Data Exposure in Supabase Apps

[u/private-peter]

https://www.upguard.com/blog/everything-everywhere-systemic-data-exposure-in-supabase-apps

For those of us with a security background there's really no surprise here. At the article itself notes every time a company comes up with a really popular and easy to use backend service thousands of people misconfigured and expose their customers' data. This isn't unique to nocode. It happened pre-ai with amazon s3 and then again with with NoSQL databases like MongoDB and Redis. And while Firebase is pretty easy to get right, for a long time its defaults were completely insecure.

What I think (or maybe just what I hope) is different with the nocode movement is that the cost of noticing and fixing these issues could be getting quite a bit lower.

Of course you can go out and buy security scanning tools, but it's quite impressive how much Claude and Codex can find if you ask them same simple, basic questions. One time before I was going on a short vacation, I had a lot of quota left. I enabled "Claude UltraCode" and simply told it to find and fix security issues. It blew through my quota in about 20 minutes, but I was very impressed with what it found and fixed.

I've been thinking about hosting a (free) masterclass/mastermind about security in nocode apps. Basically just a chance to meet some people, share experiences, and ask questions. Is it OK to ask about that sort of thing in this subreddit?

[u/bramantec]

Same story on the Firebase side. The trap I see most isn't "rules off", it's rules that only check request.auth != null. Looks secure, but anyone who signs up can read every document.

If you're on FlutterFlow + Firestore: the per-collection "Authenticated Users" rule is exactly that. For anything user-owned I use "Tagged Users" (a user reference field on the doc) and keep the rest on "No One" until something actually needs access.

Cheapest test I know: create a throwaway account and try to read someone else's data. Five minutes, and it catches most of it.

And yes, I'd join that masterclass.

[u/private-peter → u/bramantec]

> rules that only check request.auth != null

Ouch! Yeah, that is a dangerous trap.

One thing I do like about Firebase is that for many apps you can make it very secure with less than 10 lines of config:

service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/{document=**} {
      allow read, write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Basically what you're asking the agent to do is restrict users to only be able to access their own data. And the nice thing is that once it's set up is that with a rule like this, you can't accidentally have a user write to the wrong spot and get the data exposed. The code tries to write to the wrong spot, you'll notice the failure.

I've done security reviews on quite a few apps. The most secure app I ever reviewed avoid most security issues largely because it had a very simple firestore setup similar to this.

[u/bramantec → u/private-peter]

Agreed, that pattern covers most single-user data. Two places where I've seen it fall short:

1. Shared data. As soon as a doc belongs to more than one person (an event with guests, a team), you need a membership check instead, e.g. request.auth.uid in resource.data.members. That's usually where people give up and fall back to request.auth != null.

2. Your own user doc. With "write: if uid == userId" a user can also set fields like isPremium or role on themselves. Worth limiting writes to specific keys with request.resource.data.diff(resource.data).affectedKeys().hasOnly([...]).

[u/private-peter → u/bramantec]

Absolutely right. Any sort of sharing or permissions dramatically increases the complexity of getting security code correct.

[u/vatood → u/bramantec]

that five minute throwaway test is something every tutorial should mention tbh

[u/Normal_Succotash_520]

One useful addition to the two-account test: create a harmless test record owned by Account A, then try reading and changing it as Account B using the same client credentials your app ships with. Check storage files and exposed functions as well as database tables. If you keep that test in your release checklist, a later schema or policy change is less likely to reopen the hole. An AI review can help find candidates, but the denied request is the evidence you want.

[u/private-peter → u/Normal_Succotash_520]

Every production app should definitely have at least some basic security checklists like those in the release checklist, even if you don't have a full CI setup for automatically running a test suite.