How can I configure Firestore rules to allow direct document reads by ID while restricting list queries?

Firestore security rules are evaluated per document without any built‑in way to tell if the read came from a single‑document get (by ID) or from a query (listing documents). In other words, the same rule must govern both operations.

This means that if you set your rule as:

FIREBASECopied
match /rooms/{id} {
  allow read: if request.auth.uid in resource.data.participant_uids;
}

then even a get by ID will check that condition. There isn’t a way to allow a get-by‑ID (document retrieval) without membership while still enforcing that any collection query only returns rooms where the user is already a participant.

Workarounds

1. Use Cloud Functions:
   You could create a Cloud Function that retrieves a room document given its ID and bypasses the security rules by using the Admin SDK. This gives you full control over the logic.

2. Store Public Data Separately:
   You might store a publicly accessible subset of room data in another collection or field that’s safe to read without membership. Then your webapp could fetch full details (with membership checks) separately.

3. Custom Token Claims or Additional Fields:
   Although this won’t differentiate a get from a list, sometimes embedding additional metadata (such as a “public” flag) may allow you to open up some fields for all while keeping others restricted.

Conclusion

Without relying on backend functionality like Cloud Functions, Firestore security rules do not provide a mechanism to treat single‑document gets differently from list queries. It is necessary to choose one rule that applies equally to all read operations on the document.