How do I install the Mobile Webview skill?

Run npx skillmds@latest add noorqureshi/mobile-webview 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 Webview 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 Webview?

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 Webview free to use?

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

Who published Mobile Webview?

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

Mobile Webview by noorqureshi — Agent Skill

Name: Mobile Webview
Author: NoorQureshi

Mobile Webview

Exploit insecure mobile WebViews — JS-bridge abuse, file access, and XSS→native. Load when an app renders web content in a WebView/WKWebView, exposes a JS bridge, or loads attacker-influenced URLs. Signals: addJavascriptInterface, WKScriptMessageHandler, loadUrl, file:// access, deep-link → WebView.

NoorQureshi 85253f8 2.2 KB Updated Sep 17, 2026

File contents

Mobile WebView abuse

When it applies

The app shows web content in a WebView (Android WebView / iOS WKWebView) and either exposes a native JS bridge or loads URLs/content an attacker can influence (deep link, param, MITM'd http).

Why it works

WebViews blur the web/native boundary. A JS bridge (addJavascriptInterface / WKScriptMessageHandler) lets page JavaScript call native code — so XSS or a malicious loaded page can invoke native functionality. Misconfig (setAllowFileAccess, setJavaScriptEnabled, mixed content) widens it to local file theft.

Method

Find the WebView config in jadx/class-dump: setJavaScriptEnabled(true), addJavascriptInterface(obj,"name") (Android <17 = any method exposed), setAllowFileAccess, setAllowUniversalAccessFromFileURLs, and what URLs it loads.
Reach the WebView with your content: via a deep link that passes a URL param into loadUrl, a param reflected into the page (XSS), or MITM if it loads http:// (ATS/cleartext).
Abuse the bridge: from injected JS call the exposed native methods (window.name.method(...)) — read files, get device data, trigger actions the bridge exposes.
File/scheme access: file:// loads + universal file access → read app-private files; content:// tricks.

Gotchas

addJavascriptInterface on old targetSdk exposes reflection → RCE-ish; on modern it's limited to @JavascriptInterface methods — enumerate those.
Impact = what the bridge exposes + whether you can get JS to run; prove both.
iOS WKWebView message handlers are the equivalent bridge — check userContentController.

Verify success

Injected JavaScript invokes native functionality via the bridge (data read, action performed), or local files are exfiltrated through the WebView.

References

OWASP MASTG (platform/WebView); Android WebView security docs; "WebView bridge abuse" write-ups.

---name: mobile-webviewdescription: Exploit insecure mobile WebViews — JS-bridge abuse, file access, and XSS→native. Load when an app renders web content in a WebView/WKWebView, exposes a JS bridge, or loads attacker-influenced URLs. Signals: addJavascriptInterface, WKScriptMessageHandler, loadUrl, file:// access, deep-link → WebView.---# Mobile WebView abuse## When it appliesThe app shows web content in a WebView (Android `WebView` / iOS `WKWebView`) and either exposes anative JS bridge or loads URLs/content an attacker can influence (deep link, param, MITM'd http).## Why it worksWebViews blur the web/native boundary. A JS bridge (`addJavascriptInterface` /`WKScriptMessageHandler`) lets page JavaScript call native code — so XSS or a malicious loaded pagecan invoke native functionality. Misconfig (`setAllowFileAccess`, `setJavaScriptEnabled`, mixedcontent) widens it to local file theft.## Method1. **Find the WebView config** in `jadx`/class-dump: `setJavaScriptEnabled(true)`, `addJavascriptInterface(obj,"name")` (Android <17 = any method exposed), `setAllowFileAccess`, `setAllowUniversalAccessFromFileURLs`, and what URLs it loads.2. **Reach the WebView with your content**: via a deep link that passes a URL param into `loadUrl`, a param reflected into the page (XSS), or MITM if it loads `http://` (ATS/cleartext).3. **Abuse the bridge**: from injected JS call the exposed native methods (`window.name.method(...)`) — read files, get device data, trigger actions the bridge exposes.4. **File/scheme access**: `file://` loads + universal file access → read app-private files; `content://` tricks.## Gotchas- `addJavascriptInterface` on old targetSdk exposes reflection → RCE-ish; on modern it's limited to `@JavascriptInterface` methods — enumerate those.- Impact = what the bridge exposes + whether you can get JS to run; prove both.- iOS `WKWebView` message handlers are the equivalent bridge — check `userContentController`.## Verify successInjected JavaScript invokes native functionality via the bridge (data read, action performed), orlocal files are exfiltrated through the WebView.## ReferencesOWASP MASTG (platform/WebView); Android WebView security docs; "WebView bridge abuse" write-ups.

Frequently asked questions