What Is Android Dangerous Permission? Definition & Examples

A dangerous permission is an Android app permission that gives access to sensitive device data or functions and must be approved by the user at runtime. It covers things like location, camera, contacts or microphone access, rather than normal permissions granted at install time.

What makes an Android dangerous permission different

Android groups permissions by sensitivity. dangerous permission are the ones that expose sensitive data or device capabilities, so the app must ask at runtime and the user must explicitly approve each access path.

That runtime prompt is the core control boundary. It is meant to keep access to location, camera, contacts, microphone, storage or similar sensitive functions visible at the moment the app wants to use them, rather than silently assuming consent from install-time acceptance alone.

Why dangerous permissions matter in app security

Dangerous permissions shape what an app can observe, collect and influence on the device. A single granted permission can expose personal data, business messages, audio, photos, nearby devices or location history, so over-granting creates a wider attack surface and a larger privacy blast radius.

They also matter because permission prompts can be normalized. Users may approve requests without understanding the data flow, especially when the requested permission seems necessary for the app’s stated function. That makes the permission review moment a security decision, not a formality.

How Android permission prompts work

At runtime, the app requests the permission when it reaches a feature that needs it. Android then shows the user a prompt, and the app only proceeds if the permission is granted. If the user denies it, the app must handle the missing capability gracefully or fall back to a narrower experience.

Modern Android permission behavior is designed to reduce silent collection and encourage least-privilege access. In practice, that means developers should request permissions only when needed, explain the user-visible reason for the request, and avoid bundling unrelated access into one workflow. For security-sensitive mobile apps, that same design principle aligns with least privilege and zero-trust thinking.

Common mistakes and what they reveal

The most common failures are over-requesting, requesting too early, or treating permission approval as permanent trust. Apps that ask for sensitive access before the user understands the feature create unnecessary refusal rates and encourage users to grant permissions reflexively.

Another frequent problem is scope creep. An app may only need camera access for a specific feature, but later expands its use of that permission for broader collection or background behavior. When permission use drifts beyond the original user expectation, the security and privacy posture changes even if the app still functions normally.

For mobile defenders, the permission list is a useful signal, but not the whole story. Review the app’s declared permissions, its runtime behavior, its data sharing disclosures and any SDKs or embedded components that may also consume sensitive access.

Risk and Threat Considerations

Dangerous permissions can become high-impact abuse paths when an app is compromised, overly broad, or deceptive. If a malicious or vulnerable app gains access to camera, microphone, contacts or location, the result can be surveillance, credential theft support, contact harvesting or sensitive data exfiltration.

Failure mechanism: The risk emerges when a user grants access that is broader than the app genuinely needs, or when an attacker later abuses that granted capability through malicious code, SDK compromise, or unauthorized data collection.

Impact: Sensitive device data can be exposed at scale, and the permission grant can become a durable collection channel until the app is removed or the permission is revoked.

Standards & Framework Alignment

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

OWASP API Security Top 10 addresses the attack and risk surface, while 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	V6 — Authentication	Android dangerous permissions rely on runtime consent before sensitive access is used.
Recommendation — Request sensitive access only when needed and bind it to a clear authenticated user action.
CIS Controls v8	CIS-6 — Access Control Management	Dangerous permissions are device access grants that should be limited and reviewed.
Recommendation — Review and remove unnecessary permission grants to keep mobile access paths least-privileged.
NIST SP 800-53 Rev 5	AC-6 — Least Privilege	Dangerous permissions should expose only the minimum sensitive device capability required.
Recommendation — Apply least privilege so apps only receive the sensitive capabilities they truly need.
OWASP API Security Top 10	API2 — Broken Authentication	Apps that over-trust permission grants can weaken the trust boundary around sensitive functions.
Recommendation — Verify that permission-gated features fail closed when access is missing or denied.

Practitioner Guidance

Why practitioners should care: For mobile product teams, dangerous permissions are a governance decision as much as a UX decision. Each request should map to a concrete feature, a clear user benefit, and the minimum access needed to deliver that feature.

What to watch for: Repeated permission prompts, permission requests on first launch, and broad requests that are not tied to an obvious feature are all signs that the app may be overreaching. Security and privacy reviews should challenge those cases early, before users normalize the request.

Practitioner takeaway: Treat every dangerous permission as a narrow trust grant, and design the app so its core function still makes sense when that grant is denied.

Android Dangerous Permission