react-doctor/firebase-permissive-rules

A Firebase rule of `if true` or `if request.auth != null` leaves data open to everyone (or to every signed-in user), treating sign-in as authorization and exposing other users' data.

Validation prompt

Confirm the detector match and collect the required evidence before deciding whether an edit is warranted.

Fires only in Firebase rules files (firestore.rules, storage.rules, database.rules.json) on an allow <op>: if <cond> where the operation is read/write/create/update/delete/list/get (or read, write) and the condition is either the literal true (open to everyone) or request.auth != null (open to any signed-in user: treating authentication as authorization). This is the Chattr/Firewreck failure mode.

Suppress when: an allow read: if true on data that is genuinely intended to be PUBLIC (a public catalog/landing collection with no per-user/tenant scoping required), or an if request.auth != null on a collection where membership in the project IS the complete intended access policy and no narrower owner/tenant boundary exists.

Evidence boundary

The diagnostic proves only that the detector’s modeled source pattern matched. It does not prove runtime impact, product intent, rendered failure, or that one remediation is correct.

Establish the environment, repository policy, exceptions, and required rendered or runtime evidence before deciding the occurrence.

Record one outcome:

• Confirmed failure: The required evidence establishes the violation.
• Rejected: A documented exception or false-positive predicate applies.
• Needs evidence: Named evidence can still be collected.
• Unavailable: Required evidence cannot be collected in this run.
• Waived with evidence: An authorized, scoped exception applies to an established failure.
• Observation: The review records an optional tradeoff without claiming a defect.

A waiver records its scope, authority, evidence, and review condition. It is not a pass or false positive.

Default severity is registry metadata. Use the occurrence’s JSON severity after repository configuration when ordering real findings.

Fix prompt

Apply this candidate correction only after the required evidence confirms the risk.

Replace blanket conditions with ownership or membership checks that bind each rule to the caller and the resource, for example allow read, write: if request.auth != null && request.auth.uid == resource.data.ownerId, and gate tenant collections on a membership lookup. Make authority fields immutable on update and validate them on create. Reserve if true for data meant to be world-readable, and never treat request.auth != null as enough authorization for per-user or per-tenant data.

Repository-wide copy prompt

Use this repository-wide prompt only after validating each occurrence. For one occurrence, use the guidance above.