If your Android app shows web content in a WebView, especially content that can navigate to external or user-supplied URLs, there is a built-in protection you should keep on: Safe Browsing. It checks navigations against Google's list of known malicious sites and warns or blocks the user before a phishing or malware page loads, the same protection Chrome provides. It is enabled by default in WebView, so the main risk is turning it off or not knowing it exists. Here is what WebView Safe Browsing is, how it behaves, and how to use it correctly.
Short answer
Android WebView Safe Browsing checks the URLs a WebView navigates to against Google Safe Browsing's list of known malicious sites and shows a warning interstitial, or blocks the page, when it detects malware or phishing. Per Android's documentation, it is enabled by default in WebView (since Android 8.0), controlled by a manifest meta-data flag and per-WebView setting, and you can customize the response to a hit with WebViewClient.onSafeBrowsingHit(). The guidance is to keep it enabled, since it protects users navigating to malicious sites at no cost to you, and to handle hits sensibly rather than disabling the feature. Disabling Safe Browsing removes a built-in protection and exposes users to known malicious pages.
What you should know
- Safe Browsing checks navigations: against Google's list of known malicious sites.
- It is on by default: enabled in WebView since Android 8.0.
- It warns or blocks: showing an interstitial for malware or phishing pages.
- You can handle hits: with
WebViewClient.onSafeBrowsingHit(). - Keep it enabled: disabling it exposes users to known malicious pages.
What is WebView Safe Browsing?
It is the integration of Google Safe Browsing into Android's WebView. Google Safe Browsing maintains a constantly updated list of sites known to host malware or phishing, and WebView checks the URLs it navigates to against that list, the same protection that powers warnings in Chrome and other browsers. When a navigation matches a known malicious site, WebView shows a warning interstitial telling the user the page is dangerous and giving them the choice to go back to safety, rather than silently loading the harmful page. This has been enabled by default in WebView since Android 8.0, so apps generally get the protection without doing anything, which is exactly the point: a WebView that can navigate to external or user-supplied URLs benefits from screening those navigations against known threats automatically. Safe Browsing turns your WebView's navigations into checked navigations.
How does it behave?
It checks, then warns or blocks, with hooks for you to customize. The table summarizes.
| Aspect | Behavior |
|---|---|
| Default state | Enabled in WebView since Android 8.0 |
| On a malicious URL | Shows a warning interstitial or blocks the page |
| Manifest control | A meta-data flag enables or disables it app-wide |
| Per-WebView control | A setting toggles it for a specific WebView |
| Handling a hit | onSafeBrowsingHit() lets you choose the response |
By default, when Safe Browsing detects a known malicious URL, WebView presents an interstitial warning the user and offering to return to safety, which is sensible default behavior. You can adjust this: a manifest meta-data flag controls whether Safe Browsing is on for the app, a per-WebView setting toggles it for a given instance, and WebViewClient.onSafeBrowsingHit() lets you decide the response to a detected threat, for example showing the warning, going back to safety, or proceeding, along with reporting. The intent of these hooks is customization, not an invitation to disable the protection.
How do you use it correctly?
Keep Safe Browsing enabled and handle hits sensibly. The default, enabled, with a warning interstitial, is the right baseline, so the main thing is not to turn it off: do not set the manifest flag to disable Safe Browsing or toggle it off per WebView, since that removes a free protection and exposes users to known malicious pages, which matters most for any WebView that can reach external or user-supplied URLs. If you want custom behavior, implement onSafeBrowsingHit() to control how a detected threat is presented, defaulting to keeping the user safe rather than proceeding, instead of disabling the feature entirely. Initialize Safe Browsing where appropriate so it is ready before navigations occur. And combine it with your other WebView hardening, since Safe Browsing screens for known malicious sites but is not a substitute for restricting what your WebView can load and do. The principle is to leave the protection on and let it screen navigations, only customizing the response, never removing the check.
What to watch out for
The first trap is disabling Safe Browsing, via the manifest flag or per-WebView setting, which removes a built-in protection against known malicious pages; keep it on. The second is assuming Safe Browsing is your whole WebView security story, when it screens for known threats but does not replace restricting what the WebView loads and executes. The third is implementing onSafeBrowsingHit() to proceed past warnings, defeating the purpose. A pre-submission scan such as PTKD.com (https://ptkd.com) reads the compiled APK or AAB against OWASP MASVS and assesses your WebView configuration, helping you confirm protections like Safe Browsing are not disabled. The configuration itself you set in your manifest and code.
What to take away
- Android WebView Safe Browsing checks navigations against Google's list of known malicious sites and warns or blocks the user before a malware or phishing page loads.
- It is enabled by default since Android 8.0, controlled by a manifest flag and per-WebView setting, with
onSafeBrowsingHit()to customize the response to a detected threat. - Keep it enabled, especially for WebViews that can reach external or user-supplied URLs, customize the response rather than disabling the feature, and pair it with your other WebView hardening.
- Use a pre-submission scan such as PTKD.com to confirm WebView protections like Safe Browsing are not disabled in your build.
