Android Broadcast Receivers are app components that listen for system-wide or app-sent broadcast messages and react when a matching Intent arrives. They can be abused to trigger code unexpectedly, expose data through exported receivers, or let other apps invoke sensitive actions. Defenders should restrict export status, validate incoming data, and minimise privileges on receiving components.
How Android Broadcast Receivers Work
broadcast receivers are a core Android app component for receiving intents that the system or other apps send as broadcasts. They are lightweight entry points, but they still participate in app behaviour, state changes, and inter-component trust decisions.
Because they can run in response to external events, the receiver is part of the app’s attack surface even when it is not user-facing. A receiver that is enabled by default can become a trigger point for logic that developers expected to remain internal.
Why They Are Security-Sensitive
Broadcast receivers matter because they can be invoked without the normal user journey of opening an app screen. If a receiver is exported, or if its input handling is weak, another app may be able to reach functionality that was meant to stay private.
That makes broadcast handling a trust boundary. The component must assume that any received Intent can be malformed, hostile, or simply inconsistent with the app’s expected state. Sensitive actions should not be exposed through receivers unless there is a clear reason and strong validation around them.
Common Abuse Patterns
The most common problems are unexpected code execution, unauthorized triggering of privileged logic, and data exposure through exported components. A receiver can also become a bridge to higher-risk functionality if it forwards parameters into file access, account operations, or privileged internal APIs.
Android teams also need to watch for intent spoofing and confused-deputy behaviour, where a receiver accepts caller-controlled data and performs an action using the app’s own authority. Mobile App Security Guide is a useful reference for the broader mobile control surface that includes intent handling, exported components, and related Android security patterns.
Defensive Design and Review
Good receiver design starts with minimising exposure. Keep receivers non-exported unless there is a real interoperability need, narrow the intent filters to the smallest useful scope, and treat every incoming field as untrusted. Where a receiver must be reachable, validate the sender, validate the payload, and avoid routing broadcast input directly into sensitive actions.
Receivers should also be reviewed alongside the permissions and privileges of the component they can reach. If a broadcast path can wake code that reads secrets, changes state, or calls privileged services, the security question is not only whether the receiver works, but whether it should exist at all.
Defensive review should include the receiver lifecycle, the app’s exported surface, and any assumptions about who can trigger the code path. In practice, a safe receiver is one that does the minimum necessary work and delegates sensitive processing only after explicit checks.
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 | V8 — Authorization | Broadcast receivers expose callable app functions that require strict authorization checks. |
| V13 — Configuration | Receiver export status and intent-filter scope are configuration choices that shape attack surface. | |
| V16 — Security Logging and Error Handling | Receiver abuse and malformed intents need observable handling for investigation and detection. | |
| Recommendation — Enforce authorization checks before a receiver can trigger sensitive app actions. Restrict exported receivers and minimize exposed intent filters. Log receiver-triggered security-relevant events and handle malformed intents safely. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Android broadcast receivers are an application-security hardening concern inside app code and configuration. |
| Recommendation — Review receiver exposure, input validation, and privilege use during application security testing. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | A receiver should only allow callers to reach actions that access policy permits. |
| Recommendation — Enforce access rules before receiver-triggered functionality can execute. | ||
Related resources from NHI Mgmt Group
- How should security teams detect Android malware that abuses cloud services for exfiltration?
- How can mobile threat teams reduce the blast radius of Android RAT activity?
- How should security teams respond when Android apps request Accessibility permissions?
- How should security teams manage DMARC changes when receivers adopt new policy semantics at different speeds?
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 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org