AN1693: Analytic 1693
When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Defenders should validate the entirety of the URI. For example, the URI's scheme should be `https` and the URI's host should be on a list of trusted hosts.[1]
Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[2][3]
On Android, users may be presented with a popup to select the appropriate application to open the URI in. If the user sees an application they do not recognize, they can remove it.
Analyst context for executives and security teams
This analytic is about reducing Android mobile app risk before deployment by checking whether apps handle Intents, URIs, App Links, and OAuth redirects safely. The business value is preventive: weak URI or Intent handling can create avoidable exposure in mobile workflows, especially where employees use corporate apps, identity sign-in, or trusted links to reach sensitive services.
Executive priority
Security leaders should treat this as an application assurance and mobile risk governance issue, not only a SOC detection item. Ask whether Android apps approved for enterprise use are vetted for unsafe URI loading, untrusted hosts, implicit Intent handling, and OAuth native-app best practices. This supports mobile security readiness, identity assurance, compliance evidence for secure development or third-party app review, and prioritization of risky apps before they become operational dependencies.
Technical view
For Android, validate that app vetting or code review checks the full URI, including requiring appropriate schemes such as HTTPS and restricting hosts to trusted lists where applicable. Review whether apps use explicit rather than implicit Intents when appropriate, perform permission checks, verify destination app signing certificates, and use Android App Links where suitable. For mobile applications using OAuth, validate alignment with OAuth 2.0 for Native Apps guidance. Because ATT&CK provides no separate detection logic for this analytic, SOC and IR teams should treat it primarily as a preventive validation and assurance control, with any runtime findings requiring local mobile telemetry and app inventory context.
Likely telemetry
- Mobile application vetting or static analysis results for Android apps
- Android manifest and intent-filter review artifacts
- Code review or binary analysis evidence for URI validation and WebView URL handling
- Configuration evidence for App Links and trusted host handling
- OAuth redirect URI and native-app authentication design documentation
Detection direction
- Validate that app vetting rules check the entire URI, not only partial strings or the presence of a scheme.
- Tune reviews to distinguish expected Android Intent and App Link behavior from unsafe implicit routing or untrusted destination handling.
- Check for blind spots in third-party or internally developed apps that are approved for enterprise use but not subject to mobile security vetting.
- For OAuth-enabled mobile apps, include redirect handling and native-app flow review in detection engineering or application assurance test plans.
- Use user-facing Android handler selection prompts as weak supporting context only; they are not a reliable standalone detection signal.
Mitigation priorities
- Prioritize secure application vetting for Android apps used in business or identity workflows.
- Require safe URI validation practices, including trusted schemes and trusted hosts where applicable.
- Prefer explicit Intents when appropriate and apply permission checks, destination signing-certificate checks, or Android App Links as supported by the application design.
- Review OAuth native-app implementations against established best practice guidance.
- Maintain a process for users or administrators to remove unrecognized apps that appear as unexpected URI handlers.
Analyst notes and limits
This object is a MITRE mobile detection analytic for Android application vetting. It is most useful for mobile application security, identity design review, and pre-deployment assurance rather than classic network or endpoint alerting. The supplied object has no tactics and no relationship context, so conclusions should remain focused on Android Intent, URI, App Links, and OAuth handling.
Official detection content is not provided, and no relationships to techniques, software, campaigns, or mitigations were supplied. Local source code access, app vetting tooling, mobile device management data, and application architecture details are needed to determine real coverage or risk.
Analytic 1693
When vetting applications for potential security weaknesses, the vetting process could look for insecure use of Intents. Defenders should validate the entirety of the URI. For example, the URI's scheme should be `https` and the URI's host should be on a list of trusted hosts.[1]
Developers should be encouraged to use techniques to ensure that the intent can only be sent to an appropriate destination (e.g., use explicit rather than implicit intents, permission checking, checking of the destination app's signing certificate, or utilizing the App Links feature). For mobile applications using OAuth, encourage use of best practice.[2][3]
On Android, users may be presented with a popup to select the appropriate application to open the URI in. If the user sees an application they do not recognize, they can remove it.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
All related ATT&CK context
No relationships are available in the current normalized data for this object.
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 2.0 | Current bundle | db83b31571ae… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
Android_UnsafeURILoading_Sept2024
Android Developers. (2024, September 24). Webviews – Unsafe URI Loading. Retrieved March 2, 2026.
Open source URL -
[2]
IETF-OAuthNativeApps
W. Denniss and J. Bradley. (2017, October). IETF RFC 8252: OAuth 2.0 for Native Apps. Retrieved November 30, 2018.
Open source URL -
[3]
Android-AppLinks
Android. (n.d.). Handling App Links. Retrieved December 21, 2016.
Open source URL -
[4]
mitre-attack AN1693Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.