Firebase user can grant themselves privileges
Scan rule · RSC-SEC-133
- Security
- Severity: High
- CWE-269
- OWASP A01-2021
Finds `match /users/{uid}` (or a profile collection) with `allow write: if request.auth.uid == uid` without protecting the role/rights field — reported when the rules read such a field (`role`, `isAdmin`, `admin`, `plan`, `premium`) as a permission.
Why this matters
This is the Firebase counterpart to Supabase self-promotion (RSC-SEC-111). `allow write: if request.auth.uid == uid` looks clean and binds to the owner — but it only answers WHOSE document may change, not WHICH fields. Firestore has no field-level protection of its own.
If the same document holds the role, the plan or an `isAdmin` flag — and the rules reveal it by reading such a field elsewhere as a permission (`get(/…/users/$(uid)).data.role == 'admin'`) — then an account created in seconds simply writes its own `role` to `admin`.
Fix: pin the role field against its previous value in the write rule, or allow only harmless fields via `request.resource.data.diff(resource.data).affectedKeys().hasOnly([...])`. Cleaner still, keep roles in a separate collection only admins or the server can write.
Scan tier
- Repo access (deep scan)
How to fix it
Pin the role field to its previous value in the write rule (`request.resource.data.role == resource.data.role`) or allow only harmless fields via `affectedKeys().hasOnly([...])` — best of all, do not keep the role in the user document.