What are common mistakes with Android Broadcast Receivers?

Common mistakes with Android Broadcast Receivers are exporting them unnecessarily, failing to check the sender, and trusting broadcast data without validation. That can let other apps trigger sensitive actions or inject crafted inputs. Restrict exposure, require explicit permissions where appropriate, and verify intent contents before acting on them.

What developers get wrong about broadcast receiver exposure

android broadcast receivers are often treated as simple plumbing, but their exposure model is security-sensitive. If a receiver is exported without a clear reason, any app may be able to send it an intent. That turns a convenience feature into an attack surface, especially when the receiver triggers privileged work, state changes, or data handling based on untrusted input.

The core design mistake is confusing internal app communication with externally callable behavior. A receiver that only needs to hear from your own app should usually stay private. If it must be reachable from outside, the contract should be explicit and narrow, so that the receiver does not become a generic entry point for other apps to influence application logic.

This is why the Mobile App Security Guide treats intent interception and broadcast exposure as part of the broader mobile attack surface, not a niche Android quirk.

How sender trust and input handling fail in practice

Another common mistake is assuming that because a broadcast arrives inside your process, its contents are trustworthy. Broadcasts should be handled like any other externally influenced input unless the sender and delivery path are strongly constrained. A receiver that trusts extras, flags, action strings, or embedded identifiers without validation can be tricked into performing the wrong action or consuming malformed data.

Sender verification matters because the security question is not only “did an intent arrive?” but “who was allowed to cause this code path to run?” Where the operation is sensitive, require an explicit permission or another strong authorization check rather than relying on obscurity, package naming, or the assumption that only friendly apps will send the broadcast.

Broadcast receivers also become risky when they couple validation with side effects. If parsing fails after partial state changes, the app can end up in an inconsistent condition. Validate the intent contents first, then act. If the receiver needs to accept a structured payload, treat each field as untrusted until checked against expected values, type, length, and allowed state transitions.

That same pattern is why the Top 10 Secrets Management Mistakes matters here too, because overly trusting inbound data often becomes a path to leaking or misusing sensitive material.

Designing receivers so they stay narrow, intentional, and testable

The most robust receivers are specific about scope. Use the minimum exposure needed for the feature, prefer explicit over implicit reachability where practical, and separate benign event handling from actions that change permissions, session state, or sensitive configuration. If a receiver exists only to fan out internal events, keep it private and make that boundary obvious in code and manifest settings.

Where a receiver must be externally reachable, document the contract and test it adversarially. Check whether malformed extras, unexpected actions, duplicate sends, or repeated invocation can trigger unsafe behavior. Also confirm that downstream code does not silently assume the broadcast came from your own app just because the receiver itself is functioning correctly.

The Top 10 AWS IAM Mistakes is a useful reminder that overly broad trust boundaries create the same kind of exposure in cloud systems that exported receivers create on mobile.

Risk and Threat Considerations

Exported receivers and weak sender validation can let another app trigger privileged behavior, inject crafted payloads, or chain into higher-value actions such as account changes, data access, or feature abuse. The danger increases when the receiver is reachable without a permission gate and when the payload influences security-sensitive logic.

Failure mechanism: The app accepts a broadcast as trustworthy, then uses its contents to drive sensitive logic before verifying sender identity, message authenticity, or input constraints.

Impact: Attackers can provoke unintended actions, tamper with application state, or use the receiver as a stepping stone to broader abuse of the app’s privileges and data.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP ASVS 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 need authorization checks before sensitive actions run.
	V2 — Validation and Business Logic	Receiver extras and actions are untrusted inputs that require validation.
	V16 — Security Logging and Error Handling	Receiver abuse is easier to detect when suspicious invocations are logged.
Recommendation — Enforce explicit authorization before a receiver performs privileged work. Validate intent contents and allowed actions before processing them. Log unexpected receiver invocations and validation failures for review.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Exported receivers should expose only the minimum reachable capability.
	IA-5 — Authenticator Management	Sensitive broadcast paths may rely on tokens or credentials that need protection.
Recommendation — Restrict receiver exposure to the least privilege needed for the feature. Protect any secrets or tokens used to authorize broadcast-triggered actions.

Practitioner Guidance

What to verify: Confirm which receivers are intentionally exported, which are internal only, and whether each exported receiver has a documented reason to exist. If a receiver can change state, access protected data, or trigger privileged work, require a stronger control than “the broadcast came in.”

Decision rule: If the receiver does not need external callers, keep it private. If it must be callable, gate it with explicit permission checks or equivalent authorization and treat every intent extra as hostile until validated.

Common mistake: Developers often secure the activity or service path but leave the broadcast entry point open, which lets an attacker bypass the intended UI or workflow and reach the sensitive code directly.

Practitioner takeaway: The safest receiver is the one with the smallest possible audience, the narrowest possible contract, and no assumption that delivery implies trust.