Dangerous Permission

What a dangerous permission means

A dangerous permission is not just an app setting, it is a request for access to high-value device functions or user data. The core issue is whether the permission matches the app’s stated purpose, because the same capability can be legitimate in one context and excessive in another.

On mobile platforms, permission names can sound routine while the underlying access is highly sensitive. Camera, microphone, location, storage, contacts, call logs, and messages can reveal intimate behaviour patterns, support account takeover, or expose corporate information if the app does not truly need them.

Why dangerous permissions matter

Permissions are a trust boundary, because once granted they can operate continuously until the user or platform revokes them. A single overbroad grant can create long-lived exposure that survives app updates, policy changes, or a shift in how the app is used.

For security teams, the risk is not only what data the app can reach, but whether that access is proportionate to business purpose. When an app asks for more than it needs, it can become a weak point for privacy leakage, stealthy surveillance, or post-compromise abuse.

Common failure patterns

Dangerous permissions usually become a problem in three ways: the app requests access too early, retains access after the feature is no longer needed, or bundles multiple sensitive capabilities into one broad request. The governance failure is often poor justification rather than a technical exploit.

• Permission creep, where successive releases add access without a fresh review.
• Purpose mismatch, where the app function does not reasonably require the requested device capability.
• Blind approval, where users or approvers accept prompts without assessing the sensitivity of the underlying access.

At scale, this is easier to miss because mobile estates contain many apps, each with a small number of sensitive entitlements that look harmless in isolation.

How organisations should assess and control it

Review dangerous permissions against the app’s declared function, the data it actually handles, and the minimum access needed for that function. The practical question is whether the permission is essential, time-bound, and still justified in production.

Where approvals are governed centrally, use a consistent review standard and keep a current inventory of apps with sensitive access. NHIMG’s How to find high-privilege Microsoft Graph application permissions is a useful example of the same control logic applied to app permission review, even though the platform is different.

From a broader security perspective, the same least-privilege principle appears in the OWASP Non-Human Identity Top 10, which is relevant wherever software is granted durable access to sensitive resources. The general control objective is to minimise standing access and remove anything that no longer has a clear business need.

Risk and Threat Considerations

Dangerous permissions can turn a normal app into a surveillance or exfiltration channel if the access is broader than the use case. The same permission set also becomes more valuable after compromise, because an attacker who controls the app or abuses a vulnerable dependency can harvest sensitive data without needing to break the device first.

Failure mechanism: Overbroad, persistent permission grants create an access path that bypasses user expectation and can be abused for data collection, tracking, or covert capture of device content.

Impact: The result can be privacy loss, sensitive data exposure, regulatory trouble, and a larger blast radius if the app or its supply chain is compromised.

Practitioner Guidance

What to watch for: Treat repeated prompts, permission requests that appear before the feature is used, and apps that keep sensitive access after a role change as review signals. Those patterns often indicate a mismatch between the approved purpose and the access actually granted.

Governance implication: Decide who owns permission approval, how often grants are recertified, and what evidence is required before sensitive access stays enabled. If the review process cannot explain why an app needs a dangerous permission, the safest answer is usually to remove or deny it.

Related resources from NHI Mgmt Group

• Why do AI copilots make permission sprawl more dangerous?
• Android Dangerous Permission
• What is an orphaned NHI and why is it particularly dangerous?
• Why is hardcoding credentials into source code so dangerous?