Exported Broadcast Receiver

What an exported broadcast receiver does

An exported broadcast receiver is a deliberately reachable Android entry point, so the security question is not whether it exists but what can legally or maliciously activate it. Because it can be triggered from outside the app boundary, the receiver’s exported state turns a broadcast into a trust decision, which makes intent origin, action matching and permission enforcement central to its safety.

Why exported receivers are security-sensitive

The receiver can become an unintended control surface if it accepts broadcasts that were never meant for external callers. In practice, the danger is not the broadcast mechanism itself, but the gap between the receiver’s intended audience and the actual set of apps that can send it.

That gap matters because Android components often process privileged or semi-trusted work on the basis of an incoming intent. If a receiver trusts the action string, extras or calling context without strict validation, an attacker may influence app behaviour, trigger sensitive operations or steer the app into states the developer did not anticipate.

For mobile teams, this is a classic boundary problem: once a component is exported, its inputs must be treated as untrusted even when the broadcast looks routine. The design question is whether the receiver truly needs outside reachability, and if so, what limits its blast radius.

How exposure usually happens

Exposure typically comes from over-broad intent filters, missing permission checks, or logic that assumes only the app itself will ever send the broadcast. A receiver can also become reachable through platform changes, library behaviour or refactoring that leaves the exported setting in place after the original use case has changed.

Another common failure mode is treating the presence of an intent filter as proof of legitimacy. Matching an action only shows that the broadcast fits the filter, not that it came from a trusted source or carries safe data. That distinction is especially important when the receiver touches authentication state, account data, feature flags or privileged app functions.

External review should therefore focus on the component inventory, the manifest declaration, and the exact broadcast path. In Android security work, the receiver is often easier to miss than an activity or service because it is quiet, event-driven and buried in application plumbing.

Secure handling and defensive design

The safest pattern is to export only when the business need is clear and then constrain the receiver as tightly as possible. That means validating the action, checking any required permission, rejecting unexpected extras, and ensuring the receiver performs only the minimum work needed before handing off to safer internal logic.

For higher-risk receivers, developers should prefer explicit broadcasts, app-scoped communication or a permission-gated design over a broadly reachable component. Where the receiver must remain externally addressable, its code should assume hostile input, avoid sensitive side effects on receipt, and fail closed when the request does not meet expectations.

Operationally, this also means reviewing receivers during code review and release hardening, not just during vulnerability response. Exported components are part of the app attack surface, so they deserve the same discipline as network-exposed interfaces.

What to verify after deployment

Post-release testing should confirm which receivers are exported, which broadcasts can reach them, and whether any reachable path performs sensitive actions without adequate checks. This is where dynamic testing, manifest review and behaviour-driven security testing complement each other.

If a receiver has already been exposed, the review should ask whether it processed untrusted intents, whether that could have altered state, and whether any secrets, session material or privileged actions were reachable through the broadcast path. That posture review is often more valuable than a simple yes-or-no check on the exported flag.

In short, an exported broadcast receiver is not merely a message listener, it is an externally reachable interface. Its security depends on how tightly the app constrains who may trigger it, what data it accepts, and what it does once activated.

Related resources from NHI Mgmt Group

• Why do IdP backups fail even when the exported data looks complete?
• Why do exported SaaS datasets create extra identity risk?
• What breaks when digital signature certificate keys are shared or exported?
• What breaks when teams do not scan exported CRM data?