Your blog post is very helpful.
But the docs you link don't really cover this case, if I am not mistaken? Arc's case was especially hard, because executable code could be "gifted". But the same attack vector still seems relevant enough for me to be more specifically addressed by the docs.

Going that route would intuitively only be possible if the security rules were derived automatically from the source of truth for our data types (i.e., TypeScript types). But I would likely not feel comfortable with auto-generated security rules, to be honest.

We have ~20 collections holding docs with unique schemas. Some docs have tens of fields, many of which store complex data (arrays of maps). Apart from constraining writes to only these fields, is further validation even feasible? What are the limits of operations one can/should perform in them?

We don't really have validation rules that ensure adherence to a schema. We rely on type checking for that. Of course, that doesn't guarantee things at runtime, but we think it's ok in our context (constrained set of paying customers, who can only interact with their own documents).

True, my example was more of an authorization rule than a validation rule. The distinction can be tricky, because both kinds are often about restricting which fields a write may affect.

One notable example is "doesNotSetForeignTenantId", which prevents "gifting" a document to another tenant. The rule is motivated by the infamous Arc incident (see www.reddit.com/r/Firebase/c...).

I think the Firebase docs could do a much better job describing best practices to prevent such cases.

We write the few validation rules we have by hand. We always make sure to put them into functions, like “doesNotUpdateFieldX”, which helps us avoid repetition and introducing (subtle) errors.

I believe you understand it correctly. That said, compiler performance (i.e., type checking performance) is an issue in many code bases, including the one in our company.

Agreed, a universally applicable rule is hard to write. Our implementation is most definitely incomplete, but for us, it basically removed all crashes. Maybe someone feels compelled to improve on the implementation, we are happy to receive PRs.

Whether your app breaks because of the Google Translate "invasion" depends on its structure. You can make an app robust by avoiding certain patterns (e.g., sibling text nodes). We wrote an ESLint plugin to detect (some) problematic cases, which resolved the issue for us 🤞: github.com/getcouped/es...

The 2023 way of doing it could be favorable, especially to junior devs: one sees an answer plus context, one has to understand it to make it work.

But maybe AI tools could do more to close that gap, like provide rationale, pros and cons, potential weaknesses of the code suggestion etc.