This information is intended for developers with app(s) that contain Cross-App Scripting vulnerability.
One or more of your apps contain a WebView Cross-App Scripting issue which can allow malicious apps to steal user cookies and other data. Please refer to the notice on your Play Console. After the deadlines shown in your Play Console, any apps that contain unfixed security vulnerabilities may be removed from Google Play.
- Sign in to your Play Console, and navigate to the Alerts section to see which apps are affected and the deadlines to resolve these issues.
- Update your affected apps and fix the vulnerability.
- Submit the updated versions of your affected apps.
During this time your new app or app update will be in a pending publication status until your request is reviewed. If the app has not been updated correctly, you will still see the warning.
Option 1: Ensure that affected activities are not exported
Find any Activities with affected WebViews. If these Activities do not need to take Intents from other apps you can set android:exported=false for the Activities in your Manifest. This ensures that malicious apps cannot send harmful inputs to any WebViews in these Activities.
Option 2: Protect WebViews in exported activities
- Prevent unsafe file loads
Ensure that affected WebViews cannot load the cookie database. WebViews that load unsanitized file:// URLs from untrusted Intents can be attacked by malicious apps in two steps. First step: a malicious web page can write <script> tags into the cookies database. Second step: this modified cookies database file can be loaded if a malicious app sends an Intent with a file:// URL pointing to your WebView cookies database, or if the malicious webpage itself redirects your WebView to the file URL. The malicious <script> stored in the cookies database will load and execute, which can steal session information.
- Disable all file access.
- Make sure that the WebView only loads file:// URLs and verify that any loaded file:// URLs point to safe files. Note that an attacker can use a symbolic link to trick checks on the URL path. To prevent such an attack, be sure to check the canonical path of any untrusted file:// URL before loading instead of just checking the URL path.
- If you want to allow both http:// URLs and file:// URLs, implement the file:// URL verification using shouldOverrideUrlLoading and shouldInterceptRequest in WebViewClient. This ensures that all URLs loaded into WebView are verified, not limited to the URLs directly provided to a loadUrl() function call.
We’re here to help
If you have technical questions about the vulnerability, you can post to Stack Overflow and use the tag “android-security.” For clarification on steps you need to take to resolve this issue, you can contact our developer support team.