[babl-yc]

My main critique after trying Google Firestore was: (1) Lack of typed schemas with declarative definitions (2) Read/write permissions and write validation was extremely complex

From quick glance at the docs, it looks like they make progress towards the first but not sure about the latter: https://supabase.com/docs/guides/auth/row-level-security

[michelpp]

Disclaimer: I work at Supabase on database security.

The link you posted is a great guide to sensible security practices with Supabase. It's worth noting that the feature highlighted, Row Level Security (RLS) is a native Postgres feature and not Supabase specific in any way.

https://www.postgresql.org/docs/current/ddl-rowsecurity.html

One immediate benefit of using native security is that it applies to all types of database clients and tools uniformly. we're not blocked in the future adding more integrations. And it works both ways, if you are using RLS in an existing postgres deployment you can migrate to Supabase and your existing trusted policies will come with you.

It also means that we can avoid creating a whole class of security bugs by starting from scratch, and take advantage of the millions of collected human-hours of work that already exists. Security is hard because it is adversarial and it is hard to reproduce or even conceptualize a truly threatening environment without experience.

One of our guiding principals is to stand on the shoulders of the core developers and not implement our own core security model, but to use the native one as a foundation for even more powerful security concepts to come. We're actively discussing a lot of ways to make this even easier and safer for customers.

[asciimike]

A long time ago, I was the PM on Firestore security rules, which was intended to solve both of those issues.

https://github.com/FirebaseExtended/protobuf-rules-gen was the closest we got: declaring types as protobufs (because Google, of course) and then generating both security rules to guarantee validity as well as client types that would match. I wanted to add proto annotations to do additional validity (e.g. add a regex to validate the phone number string was correct, do length checks on strings, etc.), but we never quite got there (not sure proto annotations are a thing externally either).

The short answer is that backend rules engines, either in their own DSL or bolted on to e.g. SQL, are pretty tough to get right, and have a super steep learning curve. IMO, AWS API Gateway with Lambda Authorizers get this most correct: it offers a programming model that people are familiar with (writing code to access external resources to make the authZ decision) with a clear performance tradeoff (ability to cache the result for a period of time).

[tlarkworthy]

Early days but here is an open source Firebase database server which you will be able to self modify including JavaScript security rules https://observablehq.com/@tomlarkworthy/firebase-server-prot...