Broadcast Receiver is an Android component that listens for system-wide or app-generated broadcast intents. It runs code in response to events such as connectivity changes, boot completion or custom messages, and may receive them even when the app is not in the foreground.
What a broadcast receiver does in Android
A broadcast receiver is a lightweight event listener in Android. It does not own the event itself, but reacts when the platform or another app sends an intent that matches its registered filters.
This makes the component useful for state changes that matter across the device or across apps, such as boot events, connectivity shifts, locale updates, alarms, or custom app workflows. Because receivers can be triggered outside the app’s visible user flow, they are part of the app’s background execution surface.
How broadcast delivery works
Broadcasts are delivered either by manifest registration or by runtime registration, depending on the event and Android version constraints. The receiver’s filter determines which intents it can observe, and delivery may be immediate or deferred by platform rules around background execution.
The important security and reliability point is that a receiver is not a passive label, it is executable code on an event boundary. If the filter is too broad, the app can process unexpected inputs. If the receiver assumes the sender is trusted without checking, the app can expose functionality that should have been gated elsewhere.
For Android engineers, this is one of the places where event routing and trust boundaries meet. A receiver that is reachable from outside the app should be treated as an interface, not just an internal callback.
Security implications of broadcast receivers
Broadcast receivers can become an abuse path when developers expose them unintentionally or leave them able to trigger sensitive actions. A receiver that starts privileged work, reads local data, or changes application state can be a target for intent spoofing, logic abuse, or privilege boundary mistakes.
Attackers often look for receivers because they can be reachable without a visible screen, and because broadcast-driven code may run with application permissions or in a background context. That combination can make a small input-validation error much more significant than it looks in source code.
Defensive design usually comes down to tightening exposure, checking the intent source where appropriate, and ensuring the receiver only accepts the minimum event set it actually needs. Internal events should not be treated as trusted by default just because they originate inside the ecosystem.
When broadcast receivers matter most
Receivers are most important in apps that depend on asynchronous device events, system state changes, or app coordination through intents. In those cases, they influence startup behavior, background processing, and the consistency of event-driven workflows.
They also matter when a receiver is the first code path that handles a system signal. A bug there can cascade into repeated work, missed work, or unintended activation at boot or during background restoration. In higher-risk apps, the receiver deserves the same review discipline as any other externally reachable interface.
Because the component sits at the edge of app behavior, it is easy to underestimate. The safer mental model is to ask what an attacker, a misconfigured app, or an unexpected system event could make the receiver do next.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Broadcast receivers are event-entry code paths that need secure interface design. |
| Recommendation — Design receiver entry points to accept only the intended intents and enforce strict input handling. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Android receivers are application code exposed to external triggering and abuse. |
| Recommendation — Review broadcast receivers for exposed functionality, unsafe assumptions, and unintended triggers. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Receivers process external intent data and must validate what they consume. |
| Recommendation — Validate every intent extra and event path before the receiver performs privileged actions. | ||
Practitioner Guidance
Why practitioners should care: Treat every broadcast receiver as a narrow event interface with a trust decision behind it. The main question is not only whether the receiver works, but whether it can be triggered in ways that cause sensitive or unintended behavior.
What to watch for: Pay close attention to receivers that launch privileged actions, process custom intents, or accept broad filters. Those are the cases where input validation, explicit sender checks, and least-privilege design have the biggest security payoff.
Related resources from NHI Mgmt Group
- What breaks when AirPlay receiver settings and network restrictions are too permissive?
- What breaks in practice when AirPlay receiver exposure is left too broad?
- What is the difference between disabling AirPlay Receiver and restricting AirPlay access to trusted devices?
- What happens when UDP is used for log transport and the receiver cannot keep up?