Firebase Rules Hardening Skill
Purpose
Prevent overly broad Firestore access by tightening rules and documenting intent.
When to Use
- •
firestore.ruleschanges - •New collections or auth flows
- •Security review or incident response
Inputs
- •
firestore.rules - •
firebase.json - •Known access patterns (read/write flows)
Outputs
- •Rule review notes under
.agent/artifacts/{conversation-id}/firebase_rules_review.md - •Minimal diff to
firestore.rules(if needed) - •Verification results
Prerequisites
- •Clear understanding of required read/write paths
- •Firebase CLI available for emulator tests (optional)
Tools & Availability
- •Firebase CLI (optional for emulator tests)
- •If CLI unavailable, use manual rule review checklist
Methodology
- •Identify all top-level
matchblocks and their coverage. - •Enforce deny-by-default and least-privilege access.
- •Require
request.authchecks for user data. - •Validate rule conditions are specific (avoid
truecatch-alls). - •Document intent for each major rule block.
Verification
- • No broad
allow read, write: if truepatterns - • All user data paths require
request.auth - • Emulator tests run (
firebase emulators:execorfirebase emulators:start) or manual checklist documented
Pass/Fail: Pass only if all checks above are satisfied.
Risks & Mitigations
- •Over-restriction → validate required flows in emulator
- •False sense of security → document untested paths explicitly