react-doctor/firebase-query-filter-as-auth

Relying on a client-side Firestore `.where('userId', '==', …)` filter for access control is unsafe, because a client can drop the filter and read everyone's data.

• Category: Security
• Severity: warn
• Source: oxlint-plugin-react-doctor
• Framework: global
• Enabled when: client (non-server) production source files (.js/.ts/.jsx/.tsx); server/api/route dirs and test/build/doc/generated paths skipped

Validation prompt

Use this to decide whether a fired diagnostic is real or a false positive.

Fires when client code calls .where('<field>', '==', …) where <field> is an auth-shaped key — uid, userId/userID, ownerId/ownerID, orgId/orgID, tenantId/tenantID, or role — i.e. a Firestore query that scopes results by identity/tenant/role. The concern: a client query filter is not an access-control boundary, since a client can issue the same query without it. FALSE POSITIVE: the matching .where(...) is only UX/data-scoping AND the project's Firestore security rules already enforce the same request.auth.uid/membership check server-side — then the filter is defense-in-depth, not the sole gate. Only the literal == operator on a literal field-name string is matched.

Fix prompt

Use this once validation confirms the diagnostic is real.

Treat the client .where(...) as convenience only and enforce access in firestore.rules: inside the match block require request.auth != null and compare the document against request.auth.uid (or a trusted memberships/roles collection via get()), so reads and writes are denied regardless of the query. Keep the filter for scoping, never for security.