Skip to content

MASTG-TEST-0227: Debugging Enabled for WebViews

Content in BETA

This content is in beta and still under active development, so it is subject to change any time (e.g. structure, IDs, content, URLs, etc.).

Send Feedback

Overview

The WebView.setWebContentsDebuggingEnabled(true) API enables debugging for all WebViews in the application. This feature can be useful during development, but introduces significant security risks if left enabled in production. When enabled, a connected PC can debug, eavesdrop, or modify communication within any WebView in the application. See the "Android Documentation" for more details.

Note that this flag works independently of the debuggable attribute in the AndroidManifest.xml (see Debuggable Flag Enabled in the AndroidManifest). Even if the app is not marked as debuggable, the WebViews can still be debugged by calling this API.

Steps

  1. Run Static Analysis on Android with a tool such as semgrep on the app binary and look for uses of:
    • WebView.setWebContentsDebuggingEnabled being set to true.
    • ApplicationInfo.FLAG_DEBUGGABLE.

Observation

The output should list:

  • All locations where WebView.setWebContentsDebuggingEnabled is called with true at runtime.
  • Any references to ApplicationInfo.FLAG_DEBUGGABLE.

Evaluation

The test case fails if WebView.setWebContentsDebuggingEnabled(true) is called unconditionally or in contexts where the ApplicationInfo.FLAG_DEBUGGABLE flag is not checked.

To mitigate this issue:

  • Set WebView.setWebContentsDebuggingEnabled to false in production, or remove the calls entirely if they are unnecessary.
  • If WebView debugging is required during development, ensure it is enabled only when the app is in a debuggable state by checking the ApplicationInfo.FLAG_DEBUGGABLE flag at runtime.

For example:

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT) {
    if (0 != (getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE))
    { WebView.setWebContentsDebuggingEnabled(true); }
}

Note: Disabling WebView debugging this way helps protect an app already running on a device. For an attacker to exploit WebView debugging, they must have physical access to the device (e.g., a stolen or test device) or remote access through malware or other malicious means. Additionally, the device must typically be unlocked, and the attacker would need to know the device PIN, password, or biometric authentication to gain full control and connect debugging tools like adb or Chrome DevTools.

However, disabling WebView debugging does not eliminate all attack vectors. An attacker could:

  1. Patch the app to add calls to these APIs (see Patching), then repackage and re-sign it (see Repackaging & Re-Signing).
  2. Use runtime method hooking (see Method Hooking) to enable WebView debugging dynamically at runtime.

Disabling WebView debugging serves as one layer of defense to reduce risks but should be combined with other security measures.