[REQUIRED] Environment info
firebase-tools: 15.25.1
Platform: Windows
[REQUIRED] Test case
A Cloud Storage rule that reads three unique Firestore documents in a single evaluation, exercised through @firebase/rules-unit-testing against the Storage and Firestore emulators.
allow read: if firestore.exists(/databases/(default)/documents/managers/$(
firestore.get(/databases/(default)/documents/members/$(memberId)).data.owner_ref[6]
+ ' -- ' + request.auth.token.email))
|| firestore.get(/databases/(default)/documents/users/$(request.auth.token.email)).data.user_level >= 50;
[REQUIRED] Steps to reproduce
firebase emulators:start --only firestore,auth,storage, with the rule above as the Storage ruleset.- Seed a member document, a managers document keyed for a different user, and a users document whose
user_level is 50.
- Read the matched object as the user who is not a manager but has
user_level 50, so the first branch is false and the third read really fires instead of being short-circuited away.
Controls run alongside, all as expected: the same rule as the manager (two reads) is allowed, the manager branch alone as the non-manager user is denied, and the level check alone (one read) is allowed.
[REQUIRED] Expected behavior
The request is denied, the way production is documented to behave. From the cross-service rules announcement:
we enforce a limit of two Firestore document queries per rules evaluation. Querying more than two unique documents will result in rules denying access and failed requests.
https://firebase.blog/posts/2022/09/announcing-cross-service-security-rules/
[REQUIRED] Actual behavior
The request is allowed. The emulator log shows three distinct documents fetched in that single evaluation, members/<id>, then managers/<key> -- <email>, then users/<email>, and no EvaluationException.
The emulator docs already say the emulator does not enforce every production limit (https://firebase.google.com/docs/emulator-suite/connect_firestore), so this may be known and deliberate. What makes this particular limit worth adding: the emulator is the only place Security Rules can be exercised before deploy, both with @firebase/rules-unit-testing, which the docs recommend for exactly this, and with e2e suites built on the emulator. A rule that exceeds the limit passes every pre-deploy test and then denies real users in production, with no signal anywhere in between.
Please add enforcement of the two-document limit to the emulator, so a rule that production would reject is rejected before deploy. A warning when an evaluation touches more than two unique documents would already remove the false green.
[REQUIRED] Environment info
firebase-tools: 15.25.1
Platform: Windows
[REQUIRED] Test case
A Cloud Storage rule that reads three unique Firestore documents in a single evaluation, exercised through
@firebase/rules-unit-testingagainst the Storage and Firestore emulators.[REQUIRED] Steps to reproduce
firebase emulators:start --only firestore,auth,storage, with the rule above as the Storage ruleset.user_levelis 50.user_level50, so the first branch is false and the third read really fires instead of being short-circuited away.Controls run alongside, all as expected: the same rule as the manager (two reads) is allowed, the manager branch alone as the non-manager user is denied, and the level check alone (one read) is allowed.
[REQUIRED] Expected behavior
The request is denied, the way production is documented to behave. From the cross-service rules announcement:
https://firebase.blog/posts/2022/09/announcing-cross-service-security-rules/
[REQUIRED] Actual behavior
The request is allowed. The emulator log shows three distinct documents fetched in that single evaluation,
members/<id>, thenmanagers/<key> -- <email>, thenusers/<email>, and no EvaluationException.The emulator docs already say the emulator does not enforce every production limit (https://firebase.google.com/docs/emulator-suite/connect_firestore), so this may be known and deliberate. What makes this particular limit worth adding: the emulator is the only place Security Rules can be exercised before deploy, both with
@firebase/rules-unit-testing, which the docs recommend for exactly this, and with e2e suites built on the emulator. A rule that exceeds the limit passes every pre-deploy test and then denies real users in production, with no signal anywhere in between.Please add enforcement of the two-document limit to the emulator, so a rule that production would reject is rejected before deploy. A warning when an evaluation touches more than two unique documents would already remove the false green.