FCM is a push messaging service that delivers notifications and data messages from an application server to mobile apps and web clients. It uses registration tokens, message payloads, and platform-specific delivery paths to reach devices even when the app is not active.
How Firebase Cloud Messaging works
Firebase Cloud Messaging, or FCM, is a delivery layer for application messages. It lets backend systems send notifications and data payloads to mobile apps and web clients through registration tokens and platform-specific push paths, which means delivery can continue even when the app is not foregrounded.
That delivery model is useful because it decouples message creation from device reachability, but it also makes token handling and message trust boundaries part of the security picture. A push service is only as reliable as the authenticity of the sender, the integrity of the payload, and the protection of the tokens that identify recipient devices.
Why FCM is used in application architecture
Teams use FCM when they need asynchronous delivery for alerts, workflow updates, re-engagement messages, or time-sensitive events. The service is designed to bridge server-side events and client-side receipt without requiring the app to maintain a constant open connection to the device.
That architecture is attractive for scale, but it changes the failure modes. If message routing, token freshness, or platform configuration is wrong, notifications may be delayed, duplicated, silently dropped, or delivered to the wrong installation. For product teams, FCM is therefore both a messaging feature and an operational dependency.
Security boundaries in FCM delivery
FCM introduces a set of trust boundaries that practitioners need to understand. The server that sends messages must be authenticated and authorised, the token must be treated as sensitive routing material, and the payload should be designed so that a compromised message cannot directly expose secrets or trigger unsafe client behaviour.
Because FCM is often used as a bridge into production apps, message content can become a control plane for downstream actions such as opening a screen, refreshing local state, or prompting a background fetch. That makes payload design important: the message should identify an action, not carry secrets or unchecked instructions.
In practice, this means treating FCM as part of the application’s attack surface, not just a delivery convenience. The same push path that helps a legitimate backend reach users can also amplify abuse if tokens leak, sender credentials are overexposed, or client-side validation is weak.
Operational checks for safe FCM use
Before relying on FCM, organisations should know which apps, environments, and backend services can send messages, and they should verify that registration tokens are handled as sensitive values. FCM failures are often rooted in inventory gaps, token reuse, stale app builds, or misconfigured server access rather than in the push service itself.
It is also important to review vendor guidance for the exact platform configuration and message flow in use, especially where mobile apps, web clients, and backend queues all participate in delivery. For broader hardening guidance around push delivery and Firebase rules, see Firebase Security Rules Guide. Where teams have experienced Firebase exposure through weak rules, the pattern described in Firebase misconfiguration exposure 2024 is a useful reminder that backend configuration errors can turn a messaging stack into a data exposure path.
Risk and Threat Considerations
FCM becomes risky when message delivery is trusted more than the systems that create, authorize, or consume it. Stolen registration tokens, exposed backend credentials, or overly permissive message handling can let an attacker impersonate a legitimate sender, spam users, or steer client behaviour through forged notifications.
Failure mechanism: Security breaks when the backend, token lifecycle, or client-side message logic is treated as inherently trustworthy, allowing leaked routing material or weak server controls to be abused for delivery, impersonation, or unwanted actions.
Impact: The result can be user deception, notification abuse, account targeting, operational noise, and in worse cases a path from messaging compromise to broader application compromise or data exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | FCM tokens and sender secrets are sensitive routing material. |
| NHI-07 — Long-Lived Secrets | Push tokens and delivery credentials often persist beyond safe lifetimes. | |
| Recommendation — Protect FCM tokens and backend credentials from leakage and reuse. Rotate or revoke stale FCM-related secrets and tokens promptly. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | FCM delivery depends on protecting and managing authenticating material. |
| AC-6 — Least Privilege | Only approved services should be able to send push messages through FCM. | |
| Recommendation — Manage FCM sender credentials and tokens through lifecycle controls. Restrict FCM send privileges to the minimum required services. | ||
| OWASP API Security Top 10 | API2 — Broken Authentication | Message send paths and backend access must be authenticated before delivery. |
| Recommendation — Authenticate every backend path that can send FCM messages. | ||
Practitioner Guidance
Why practitioners should care: FCM is not just a transport service, it is a privileged path into production clients, so its sender credentials, registration tokens, and payload semantics need ownership. If the message channel is treated as low risk, the organisation can end up with a trusted delivery path that attackers can abuse more easily than the application itself.
What to watch for: Reused or long-lived tokens, unexpected senders, abnormal message volume, and payloads that contain sensitive data or unsafe client directives are strong warning signs. A mature implementation keeps the message minimal, validates the backend that issues it, and assumes that any client-side action triggered by a push message must still be verified locally.
Related resources from NHI Mgmt Group
- Why do cloud email platforms create identity risk beyond messaging security?
- How should healthcare organisations implement ePHI protection across cloud, devices, and messaging workflows?
- Why do identity governance programs need consistent partner-facing messaging in cloud security markets?
- What is the difference between HTTP-based and gRPC-based log delivery for cloud messaging integrations?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org