Firestore IAM Roles: Who Can View and Edit Your Data

Updated September 26, 2026

Two separate systems control access to Firestore: security rules and IAM. Mixing them up leads either to teammates who can't see data they need, or to rules loosened in ways that expose data to every user of your app. This guide explains which one applies when, and which roles to grant.

Security rules vs IAM

	Security rules	IAM
Who they're for	Your app's end users	Project members and service accounts
Applies to	Firebase client SDKs (web, iOS, Android)	Server libraries, the REST API, the console, and admin tools
Identity	Firebase Authentication user	Google account or service account

Requests made with IAM credentials, including the Firebase console, the Admin SDK, and tools like Firewatch, are not evaluated against your security rules. So if a teammate can't see data in an admin tool, the fix is an IAM role. Never loosen rules to something like allow read: if request.auth != null for that, which would let every signed-in user of your app read the data.

The roles that matter

Role	Grants	Give it to
`roles/datastore.viewer` Cloud Datastore Viewer	Read documents and metadata	Support, analysts, anyone who only needs to look
`roles/datastore.user` Cloud Datastore User	Read and write documents	Developers who edit data
`roles/datastore.owner` Cloud Datastore Owner	Full access, including managing databases and indexes	Team leads and admins
`roles/editor`, `roles/owner`	Broad access to the whole project	Avoid for data access; far more than needed

To see a project in tools that list your Firebase projects, the account also needs read access to the project itself, for example the Firebase Viewer or Viewer role.

Granting a role

In the Google Cloud console, open IAM & Admin → IAM, click Grant access, add the person's email, and choose the role. Or from the command line:

gcloud projects add-iam-policy-binding my-project \
  --member="user:alice@example.com" \
  --role="roles/datastore.viewer"

With multiple Firestore databases in one project, IAM conditions can limit a role to a specific database, so a teammate can edit staging data without touching production.

Least privilege in practice

Default people to Viewer; upgrade to User only for those who edit data.
Prefer separate projects (or databases with IAM conditions) for production and staging.
Avoid long-lived service-account keys for humans; they don't expire and are easy to leak.
Review IAM grants when people change teams or leave.

How Firewatch uses these roles

Firewatch signs you in with Google and calls Firestore with your own short-lived token, so it has exactly your IAM role on each project: a Viewer can browse and export, a User can also edit and import. There are no service accounts or keys, and your security rules don't need to change. If you see “Permission denied”, the troubleshooting page lists the fixes.