Broadcasts are how Android components and apps announce events, and they cut both ways for security. A broadcast receiver that any app can send to can be triggered or fed crafted data by a malicious app, and an implicit broadcast you send can be read by any app listening for it. Neither is a problem when the broadcast is internal and trusted; both are when the boundary to other apps is open. Modern Android also restricts implicit broadcasts, which nudges you toward safer patterns. Here is what to watch when sending and receiving broadcasts, and how to keep them secure.
Short answer
A broadcast receiver handles broadcast events, and the security risks are an exported receiver that any app can send to, letting a malicious app trigger it or supply crafted data, and an implicit broadcast you send that any app with a matching receiver can read. Per Android's guidance, the defenses are to keep receivers non-exported unless they must accept external broadcasts, protect them with permissions and validate incoming intents, and avoid sending sensitive data in implicit broadcasts, using explicit broadcasts or in-app event mechanisms instead. Modern Android also limits implicit broadcasts, so prefer explicit, app-internal communication for your own events. Treat any broadcast crossing the app boundary as untrusted.
What you should know
- Exported receivers accept external broadcasts: any app can send to them.
- Implicit broadcasts are readable: any app with a matching receiver gets them.
- Validate incoming broadcasts: a malicious app can craft them.
- Keep internal events internal: use explicit or in-app mechanisms.
- Modern Android restricts implicit broadcasts: prefer explicit communication.
What is a broadcast receiver, and what is the risk?
It is a component that responds to broadcast intents, system events like connectivity changes, or app events you define. The risk has two sides. On the receiving side, if your receiver is exported, any app can send it a broadcast, so a malicious app could trigger the receiver or supply a crafted intent that your handler then acts on, which is a problem if the receiver does something sensitive or trusts the intent's contents. On the sending side, if you send an implicit broadcast, one identified by an action rather than targeted at a specific component, any app that registered a receiver for that action receives it, so sensitive data in the broadcast leaks to other apps. Because broadcasts can cross the boundary between apps, both an exported receiver and an implicit broadcast are points where untrusted apps can interact with your event flow.
Sending versus receiving broadcasts safely
The risk differs by direction. The table separates them.
| Direction | Risk | Safer approach |
|---|---|---|
| Receiving on an exported receiver | A malicious app triggers it or sends crafted data | Keep it non-exported, or require a permission and validate the intent |
| Sending an implicit broadcast | Any app with a matching receiver reads it | Use an explicit broadcast or an in-app mechanism |
| Internal app events | Leaking them via global broadcasts | Use in-process events, not system broadcasts |
The pattern is that anything global, an exported receiver or an implicit broadcast, is reachable by other apps, while anything explicit and internal is contained. For your own app's events, there is no reason to use a global broadcast that other apps can see or send; an in-app event mechanism keeps it private. Reserve external broadcasts for when you genuinely need to communicate across apps, and secure them when you do.
How do you secure broadcasts?
Keep them internal where possible, and protect the rest. For events within your own app, use in-process communication, an in-app event bus, observable state, or explicit broadcasts targeted at your own components, rather than implicit broadcasts that other apps can receive. For a receiver that must accept broadcasts from outside, keep it non-exported unless it truly needs external input, and when it does, protect it by requiring a permission, ideally signature-level so only your own apps can send to it, and validate the incoming intent and its extras rather than trusting them. Do not put sensitive data in an implicit broadcast, since you cannot control who receives it. And lean on modern Android's restriction of implicit broadcasts as a prompt to move your own events to explicit, internal channels. The principle is to keep broadcasts that carry or trigger anything sensitive away from other apps.
What to watch out for
The first trap is an exported receiver that acts on or trusts a broadcast any app can send; keep it non-exported or require a permission and validate the intent. The second is sending sensitive data in an implicit broadcast that other apps can read; use explicit or in-app communication. The third is using global broadcasts for internal events when an in-process mechanism would keep them private. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and surfaces your exported components, including broadcast receivers, so you can confirm none is needlessly exposed before you ship. The broadcast handling you secure in your code.
What to take away
- A broadcast receiver's risks are an exported receiver any app can send to and an implicit broadcast any app can read.
- Keep receivers non-exported unless they must accept external broadcasts, and when exported, require a permission and validate the incoming intent.
- Do not send sensitive data in implicit broadcasts, and use explicit broadcasts or in-app mechanisms for your own internal events.
- Use a pre-submission scan such as PTKD.com to confirm no broadcast receiver is needlessly exposed before you ship.
