How do IAM teams know whether Firebase custom token use is expanding blast radius?

Check whether one authenticated session unlocks several Firebase services with the same trust decision. If Firestore, Storage, Realtime Database, and callable functions all accept the session, the blast radius is broader than the login screen suggests. Scope review has to include downstream service access, not just authentication success.

Why This Matters for Security Teams

Firebase custom tokens can look harmless because they are “just” a login mechanism, but the security question is whether that login decision opens multiple services with the same trust boundary. When one session can reach Firestore, Storage, Realtime Database, and callable functions, the identity is no longer limited to authentication. It has become a cross-service access grant, which is exactly how blast radius expands unnoticed.

This is where teams often misread the control point. They review token issuance, but not the downstream permissions inherited by the session. That gap matters because secret sprawl and token reuse are common failure modes in modern app stacks, as seen in the Guide to the Secret Sprawl Challenge and the Salesloft OAuth token breach. In parallel, NIST guidance on access control in NIST SP 800-53 Rev 5 Security and Privacy Controls reinforces that authorization scope must be explicit, reviewable, and bounded. In practice, many teams discover the blast radius only after a compromised token reaches more Firebase services than the original login flow ever advertised.

How It Works in Practice

IAM teams should treat Firebase custom token use as a cross-service authorization problem, not only an authentication event. The key question is whether the custom token establishes a single identity context that multiple Firebase products trust without additional policy checks. If so, the effective privilege is the union of all downstream service permissions, not the intent of the login screen.

A practical review should trace the token from issuance to enforcement. That means checking:

• Which Firebase services accept the same authenticated session without separate authorization decisions.
• Whether Firestore rules, Storage rules, and function-level checks are independently scoped.
• Whether the token maps to a coarse app role instead of a narrow workload or user context.
• Whether token lifetime and refresh behaviour allow prolonged reuse after the initial trust decision.

This is also where workload identity thinking helps. Rather than assuming “authenticated means safe,” teams should ask what the token proves, for how long, and against which service. The broader NHI lesson from The 2024 Non-Human Identity Security Report is that most organisations already recognise their NHI practices lag behind human IAM, and that gap becomes more visible when dynamic access spans multiple systems. The same principle appears in NIST control families: verify least privilege, separate duties, and continuous monitoring, rather than relying on a single session grant. Firebase teams should also compare their pattern against NHI incidents like the Dropbox Sign breach, where trust in one identity path enabled broader access than intended.

In practice, the strongest signal of excessive blast radius is when revoking one custom-token trust path would break several unrelated app functions at once. These controls tend to break down in multi-tenant apps with shared backend functions and broad default Firestore or Storage rules because the same session becomes the de facto master key.

Common Variations and Edge Cases

Tighter session scoping often increases implementation overhead, requiring organisations to balance finer-grained access against developer friction and rule complexity. That tradeoff is real, especially in Firebase environments that were built for speed first and segmentation second.

There is no universal standard for this yet, but current guidance suggests treating any custom token that unlocks several services as a candidate for blast-radius reduction. Edge cases include shared backend jobs, admin consoles, and multi-tenant applications where one identity legitimately needs broader reach. Even then, broad access should be deliberate, logged, and time-bounded rather than implied by default session trust.

Watch for these exceptions:

• Callable functions that proxy to multiple data stores, making the function the real policy choke point.
• Offline-capable clients that cache access longer than the custom token’s intended lifetime.
• Service accounts or backend-generated custom tokens that blur the line between user access and workload access.

Where teams get into trouble is assuming Firebase rule coverage automatically limits impact. It does not, unless each service has distinct authorization logic and the token cannot be repurposed across unrelated operations. In environments with shared admin tooling, legacy rules, or broad backend fan-out, the blast radius often grows faster than the initial authentication review suggests.

Related resources from NHI Mgmt Group

• How do IAM teams know whether token controls are actually working?
• How do security teams know whether PAM is actually reducing blast radius?
• How do identity teams know whether blast radius is actually under control?
• How do security teams know whether blast-radius controls are working?