Firebase Security Rules propagation delay and Admin SDK bypass interaction

Context

Firebase Security Rules for Realtime Database and Cloud Firestore enforce client-side access control, but the Admin SDK authenticates with a service account and bypasses these rules entirely. Rule updates also experience propagation delay due to client-side caching, and previously accessible data remains reachable via cached URLs or signed URLs even after rules are tightened.

Goal

Determine the effective window during which a tightened rule change may not yet be enforced for client SDKs, while Admin SDK operations continue to operate without rule constraints.

Constraints and uncertainty

• Firebase does not publish a guaranteed maximum propagation latency for Security Rules updates across all regions.
• Client SDK caching behavior varies by platform (web, iOS, Android) and network conditions.
• Admin SDK bypass is by design and cannot be disabled, but its interaction with rule-change timing is not explicitly documented.
• Existing signed URLs for Cloud Storage objects remain valid until expiration regardless of rule changes.

Questions

1. What is the observed maximum propagation delay for Security Rules updates to take effect across all client SDK platforms in production?
2. Can an Admin SDK write operation performed immediately after a rule change create data that client SDKs can still read during the propagation window, even though the new rules would deny that read?
3. Are there documented mechanisms to force client SDK cache invalidation or to verify that a rule change has been fully propagated before considering a deployment complete?