Audit and secure Firestore security rules for proper access control

Summary

Firestore security rules are referenced but their contents are not reviewed here. Overly permissive or misconfigured rules may expose sensitive project/user/task data to unauthorized access or modification from client-side SDKs or untrusted actors.

Key Risks

• Overwhelming risk if rules use allow read, write: if true; or randomly permissive allow statements.
• Firestore rules changes may be incorrectly tested only on local dev, not emulator or production.

Recommendations

• Review and restrict firestore.rules to limit all non-privileged reads/writes. Follow the principle of least privilege.
• Use Firebase Emulator Suite to test rules against a variety of real scenarios and add rules unit tests.
• Regularly deploy/test rules via CI, ensure ALL changes to Firestore rules pass SAST and unit test gates.
• Remove any rules allowing full collection reads or writes by default.

Severity: High – all production data may be exposed without proper rules.

Example:

// BAD
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true; // DANGEROUS!!
    }
  }
}

Files: firestore.rules, firebase.json (deploy config)

Resolve this before adding new users or exposing any data externally.

Start by reviewing firestore.rules and the deployment settings in firebase.json, then inspect how the Firestore collections are accessed. Use the Firebase Emulator Suite to test authenticated and unauthenticated read/write scenarios and add rules unit tests where the project supports them. Done means access follows least privilege, broad default access is removed, and the rules pass the relevant tests before deployment.