MASTG-BEST-0008: Debugging Disabled 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.).
Ensure that WebView debugging is disabled in production builds to prevent attackers from exploiting this feature to eavesdrop, modify, or debug communication within WebViews.
- Set
WebView.setWebContentsDebuggingEnabledtofalsein 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_DEBUGGABLEflag 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:
- Patch the app to add calls to these APIs (see Patching), then repackage and re-sign it (see Repackaging & Re-Signing).
- 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.