How do I install the Mobile Deeplink Abuse skill?

Run npx skillmds@latest add noorqureshi/mobile-deeplink-abuse in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Mobile Deeplink Abuse safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Mobile Deeplink Abuse?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Mobile Deeplink Abuse free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Mobile Deeplink Abuse?

NoorQureshi (@noorqureshi) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Mobile Deeplink Abuse by noorqureshi

Name: Mobile Deeplink Abuse
Author: NoorQureshi

Mobile Deeplink Abuse

Abuse deep links / custom URL schemes / intents for redirect, token theft, and reaching internal screens. Load on custom schemes (myapp://), App Links/Universal Links, exported activities, or "open in app". Signals: intent-filters in the manifest, WebView loading deep-link params, OAuth redirect via a custom scheme.

NoorQureshi Updated Sep 17, 2026

File contents

Deep link / URL scheme / intent abuse

When it applies

The app registers custom URL schemes or App/Universal Links, or exports activities that accept data. A malicious link (in a web page, another app, or a QR) can then drive the app.

Why it works

Deep-link handlers receive attacker-controlled data and often trust it: they redirect, load it into a WebView, pass it to auth flows, or open privileged screens without re-checking who sent the intent. Custom schemes aren't verified for ownership (unlike App Links), so any app can claim them.

Method

Map handlers: from the manifest, list intent-filter schemes/hosts and exported activities; read jadx for how each parameter is used.
Test open redirect / token theft: if a deep link takes a redirect/return_url or the OAuth callback is a custom scheme, point it at attacker-controlled to steal codes/tokens.
WebView injection: if the deep link's data reaches loadUrl()/evaluateJavascript, try XSS/JS-bridge abuse (android-webview in mobile-android-assessment).
Reach internal screens: adb shell am start -a android.intent.action.VIEW -d "myapp://internal/admin?..." to invoke functionality meant to be gated.
Intent redirection: a component that forwards an attacker-supplied nested intent can be used to launch non-exported components.

Gotchas

Custom-scheme OAuth is inherently interceptable — that's the classic account-takeover chain.
App Links (verified domains) resist scheme-hijacking; custom schemes don't.
Test both from a web page (<a href="myapp://...">) and from adb — behaviour can differ.

Verify success

A crafted link causes token/code disclosure to you, XSS in the app's WebView, or reaches a screen/action that should require prior auth.

References

OWASP MASTG (platform interaction); Android App Links docs; deep-link ATO write-ups.

---name: mobile-deeplink-abusedescription: Abuse deep links / custom URL schemes / intents for redirect, token theft, and reaching internal screens. Load on custom schemes (myapp://), App Links/Universal Links, exported activities, or "open in app". Signals: intent-filters in the manifest, WebView loading deep-link params, OAuth redirect via a custom scheme.---# Deep link / URL scheme / intent abuse## When it appliesThe app registers custom URL schemes or App/Universal Links, or exports activities that acceptdata. A malicious link (in a web page, another app, or a QR) can then drive the app.## Why it worksDeep-link handlers receive attacker-controlled data and often trust it: they redirect, load itinto a WebView, pass it to auth flows, or open privileged screens without re-checking who sentthe intent. Custom schemes aren't verified for ownership (unlike App Links), so any app can claim them.## Method1. **Map handlers**: from the manifest, list `intent-filter` schemes/hosts and exported activities; read `jadx` for how each parameter is used.2. **Test open redirect / token theft**: if a deep link takes a `redirect`/`return_url` or the OAuth callback is a custom scheme, point it at attacker-controlled to steal codes/tokens.3. **WebView injection**: if the deep link's data reaches `loadUrl()`/`evaluateJavascript`, try XSS/JS-bridge abuse (`android-webview` in `mobile-android-assessment`).4. **Reach internal screens**: `adb shell am start -a android.intent.action.VIEW -d "myapp://internal/admin?..."` to invoke functionality meant to be gated.5. **Intent redirection**: a component that forwards an attacker-supplied nested intent can be used to launch non-exported components.## Gotchas- Custom-scheme OAuth is inherently interceptable — that's the classic account-takeover chain.- App Links (verified domains) resist scheme-hijacking; custom schemes don't.- Test both from a web page (`<a href="myapp://...">`) and from `adb` — behaviour can differ.## Verify successA crafted link causes token/code disclosure to you, XSS in the app's WebView, or reaches ascreen/action that should require prior auth.## ReferencesOWASP MASTG (platform interaction); Android App Links docs; deep-link ATO write-ups.

Frequently asked questions