Fix: Disallow read-access to nested user collections for disabled users

[Copilot]

Problem

Users with disabled accounts could still read their own nested collections (such as allergyIntolerances, appointments, medicationRequests, observations, questionnaireResponses, etc.) through Firestore security rules. This was due to a previous workaround for a client application bug where token refresh wasn't ensured before snapshot listeners were installed during enrollment.

With the client-side issue now resolved, we can properly restrict access for disabled users.

Solution

Updated the Firestore security rule for users/{userId}/{collectionName}/{documentId} to use the isUser(userId) helper function instead of a direct authentication check. This ensures that the isAuthenticated() function is called, which properly checks if a user is disabled before granting access.

Changed in firestore.rules (line 166):

  allow read: if isAdmin()
-   || (request.auth != null && request.auth.uid == userId)
+   || isUser(userId)
    || isOwnerOrClinicianOfSameOrganization();

The isUser() helper internally calls isAuthenticated(), which returns false when request.auth.token.disabled == true, effectively blocking disabled users from accessing their nested collections.

Testing

Added comprehensive test coverage in userCollections.test.ts with a new test case: "disabled users cannot access their own nested collections" that verifies:

• ❌ Disabled users cannot read their own nested collections
• ✅ Admins can still access disabled user collections
• ✅ Owners and clinicians of the same organization can still access disabled user collections

Important Notes

• User documents remain accessible: Disabled users can still read their own user document at users/{userId}. This is intentional and allows users to view their account status.
• Only nested collections are restricted: The fix specifically targets clinical data collections while maintaining backward compatibility for all enabled users.
• Minimal change: Only 1 line changed in the security rules, following the existing pattern used for write operations.

Fixes #

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• metadata.google.internal
  • Triggering command: node /home/REDACTED/work/ENGAGE-HF-Firebase/ENGAGE-HF-Firebase/functions/node_modules/.bin/jest --runInBand (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Disallow read-access to nested user collections for disabled users</issue_title>
<issue_description>### Problem

Currently, a user has read access to some of its nested collections, even if they have a disabled account. This is the case due to a previous bug of the client applications where it wasn't ensured that a token refresh happens before snapshot listeners are installed during enrollment. With this issue out of the way, we can restrict the rules again.

Solution

Make sure a user is not only authenticated with the respective userId in the Firestore rules, but also check that the user is fully enrolled and enabled.

Additional context

No response

Code of Conduct

• I agree to follow this project's Code of Conduct and Contributing Guidelines</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #213

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.