Audit and secure Firestore security rules for proper access control

[iamitprakash]

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.