The problem with full-access monitoring tools
Every time a developer opens the Firebase console, the AWS management console, or any cloud provider's web interface to check production metrics, they're doing so with credentials that have write access to that environment. The session is authenticated to an account that can delete databases, modify security rules, and change billing settings — even if all they wanted to do was check crash rates.
This pattern is so normalised in DevOps workflows that most teams never question it. But the security implications are significant: every monitoring session is a potential attack surface. Session hijacking, browser extension compromise, or a social engineering attack during an on-call check creates a write-access window into your production environment.
The principle of least privilege, applied to observability
The principle of least privilege — granting only the minimum permissions required to perform a task — is a foundational security concept that most teams apply to service accounts and CI/CD pipelines but rarely apply to their own monitoring workflows. A developer checking "is the app crashing?" needs read access to Crashlytics. They do not need write access to Firestore, the ability to modify Authentication settings, or the power to delete a Cloud Function.
The argument for least-privilege monitoring is not that your developers are untrustworthy. It's that human error, credential theft, and phishing attacks happen in proportion to the attack surface. A monitoring credential that can only read metrics can't be abused to delete production data — regardless of how the credential was compromised.
How read-only monitoring reduces blast radius
Blast radius is the scope of damage that can result from a security incident. A full-access credential compromised in a phishing attack has a blast radius that includes every write operation your cloud provider permits. A read-only credential has a blast radius limited to data exposure — still serious, but categorically different from data destruction or service disruption.
For Firebase specifically, the blast radius difference is stark:
- Full-access Firebase credential compromised: Attacker can delete all Firestore collections, modify security rules to expose all data publicly, disable Authentication, run Cloud Functions to exfiltrate data, and incur arbitrary billing charges
- Read-only Firebase credential compromised: Attacker can read the metrics and data accessible to the monitoring scope — a data breach risk, but not a service destruction risk
The 2026 shift: read-only tools as a product category
Until recently, purpose-built read-only monitoring tools were limited to mature enterprise platforms with established role separation (Datadog, Grafana, Splunk). Cloud provider consoles were monolithic — you got full access or nothing.
2024–2026 has seen the emergence of a new product category: purpose-built read-only companion apps for cloud providers. These tools request minimal OAuth scopes, surface the metrics that matter for on-call decisions, and by architectural constraint cannot modify production state. The Firebase ecosystem has seen several such tools emerge, with Firepulse being one of the first on Android.
The pattern is also emerging in enterprise tooling: many companies now prohibit production console access on personal devices and require dedicated monitoring apps or VPN + restricted-scope credentials for on-call work. The 2026 SANS Institute DevSecOps survey found that 41% of enterprises have formal policies separating read-only monitoring access from write-access deployment credentials — up from 24% in 2023.
OAuth scopes as the enforcement mechanism
For Google Cloud and Firebase, read-only access is enforced through OAuth scopes at the credential level. The relevant scopes for Firebase monitoring are all read-only variants:
firebase.readonly— read Firebase project configuration and metadataanalytics.readonly— read Google Analytics datamonitoring.read— read Cloud Monitoring metricslogging.read— read Cloud Logging entriescloud-platform.read-only— read Google Cloud resources without write access
A tool that requests only these scopes cannot write to Firestore, modify security rules, or trigger Cloud Functions — even if the underlying Google account has full project access. The scope restriction is enforced by Google's OAuth infrastructure, not by the tool itself. This means the security guarantee holds even if the tool's code were completely compromised.
The on-call workflow shift in practice
For a team with 3–5 developers sharing Firebase on-call responsibilities in 2026, the practical workflow change looks like this:
- Normal monitoring: Check Firepulse or equivalent read-only tool on your phone during on-call. You can see crash rates, Firestore usage anomalies, and function error rates without opening the Firebase console.
- Incident investigation: Read-only monitoring identifies the problem and its scope. You understand what's happening before deciding whether action is needed.
- Write access when needed: If a change is required (security rule update, function rollback, configuration change), open the Firebase console with full credentials on a trusted device. The decision to use write access is deliberate, not habitual.
- Post-incident review: The separation between monitoring and write-access actions creates a natural audit trail — monitoring events are separate from configuration changes.
Limitations of the read-only console approach
Read-only monitoring is not a complete security solution. Data exposure through compromised read-only credentials remains a serious risk. For projects with sensitive personal data, PII, or financial information, even read-only access to Firestore metrics and logs can expose sensitive information.
The read-only approach also creates an operational friction: when something is broken and you need to fix it immediately, context-switching from a monitoring app to a full-access console adds latency to your incident response. This tradeoff is worth it for most teams but requires designing on-call runbooks that account for the two-step flow.
Firebase's read-only scope model: a reference implementation
Firebase's OAuth scope design is worth studying as a reference for any developer building monitoring tools. The granularity of read-only scopes — separate scopes for Analytics, Crashlytics, monitoring, and logging — allows tools to request exactly what they need and nothing more. A crash monitoring tool can request only firebase.readonly and monitoring.read without needing analytics.readonly.
This granularity is something to emulate when building internal tooling. Rather than creating a single service account with broad project access, create purpose-specific service accounts with the minimum scopes required for each use case: one for deployment, one for monitoring, one for analytics reporting.
Related
- Post
Mobile Backend Security Trends 2026
Firebase data leaks, token management, and App Check adoption in 2026.
- Tool
Firebase Security Rule Tester
Audit 10 common Firestore and RTDB security misconfigurations.
- Post
Top 10 Firebase Misconfigurations 2026
The most common Firebase mistakes and how to avoid them.
- App
Firepulse overview
Firebase read-only mobile console — all scopes are read-only by design.
