MASTG-BEST-0012: Disable JavaScript in WebViews
Enabling JavaScript is not a vulnerability by itself. In real apps it is often required for legitimate functionality, such as rendering modern web applications, interactive account portals, support centers, payment or login flows, or hybrid app content built with web technologies. Frameworks such as Ionic and Capacitor are built around a WebView that runs JavaScript application code, and react-native-webview exists specifically to render web content in a native view.
Android's guidance associates unsafe use of JavaScript enabled WebViews with cross-app scripting. JavaScript does increase the attack surface of a WebView, but severe cases typically happen when it is combined with one or more of the following conditions: loading untrusted or weakly validated content, exposing JavaScript bridges, allowing permissive file or content access, or using unsafe URL loading.
Keep JavaScript Disabled in WebViews When Not Required¶
JavaScript is disabled by default in WebViews. If JavaScript is not required, do not enable it in the first place or explicitly disable it in WebViews with setJavaScriptEnabled(false).
- Keep JavaScript disabled for WebViews that only display static or minimally interactive content. Good candidates include static help pages, legal text, release notes, or other controlled content that does not need client-side scripting.
- Only enable JavaScript when the WebView is intentionally used to run trusted web application logic. Good candidates include hybrid app screens, complex internal web apps, single-page applications, and web-based user experiences that depend on JavaScript to render or function.
Use Alternatives to WebViews for External Content When Feasible¶
If you only need to open external web content, consider using Custom Tabs instead of embedding a WebView. If you are shipping a web app you control, Trusted Web Activities may also be appropriate. These options move rendering into the browser context rather than your app's WebView, which can reduce app specific WebView risk. They do not remove the need to secure the web content itself.
Custom Tabs are especially appropriate for authentication and other browser-based flows because Android recommends them for sign-in, noting that the host app cannot inspect the content. Trusted Web Activities also prevent the host app from having direct access to web content or web state such as cookies and localStorage.
Hardening WebViews When JavaScript Is Required¶
If JavaScript is required, apply WebView specific hardening measures, covered in related MASTG best practices, to mitigate the increased attack surface. This includes, but is not limited to:
- Only load expected and allowlisted origins.
- Validate scheme and host before calling
loadUrl,shouldOverrideUrlLoading, or similar APIs. - Disable file and content access unless they are strictly needed ( Securely Load File Content in a WebView and Disable Content Provider Access in WebViews).
- Avoid exposing JavaScript bridges to untrusted content ( Prefer Origin Scoped Messaging Over Legacy JavaScript Bridges).
- Enable Safe Browsing where supported by the WebView implementation, for example by calling
WebSettings.setSafeBrowsingEnabled(true)(available since Android 8.0, API level 26).
Tests¶
MASTG-TEST-0252: References to Local File Access in WebViews MASTG-TEST-0334: Native Code Exposed Through WebViews MASTG-TEST-0250: References to Content Provider Access in WebViews MASTG-TEST-0253: Runtime Use of Local File Access APIs in WebViews MASTG-TEST-0251: Runtime Use of Content Provider Access APIs in WebViews