onReceivedSslError

What the callback means in practice

onReceivedSslError is not a passive notification, it is a control point. When Android WebView encounters a certificate validation problem, the app decides whether the load continues or stops. That choice directly determines whether the user’s session is protected by a verified TLS connection or exposed to interception, downgrade, or spoofing.

The callback matters because WebView is often used for login flows, embedded portals, and other sensitive content. If the app treats the error as informational and proceeds anyway, it can nullify TLS protections even when the server certificate problem would otherwise have blocked the connection.

Why this is dangerous in WebView

Certificate errors in WebView are dangerous because they can be converted into silent trust decisions. An attacker who can interfere with network traffic, or who can cause the app to accept an untrusted certificate, may be able to read or alter page content, harvest credentials, inject scripts, or impersonate the intended site.

That risk is especially serious in hybrid apps where the WebView hosts authentication, payment, or account-management pages. The security failure is not the presence of the callback itself, but the app’s policy for handling it. Proceeding on error turns certificate validation from an enforcement mechanism into a best-effort warning.

How developers should think about trust decisions

The safest design assumption is that a certificate error represents a broken trust chain until proven otherwise. The app should only continue when there is a narrowly justified, explicitly documented reason, such as a controlled test environment with a temporary and tightly scoped exception. For production traffic, the expected behavior is aborting the load rather than overriding validation.

This callback also sits alongside other WebView trust controls, so it should be considered with allowlists, network security configuration, and any certificate pinning strategy. The important principle is consistency: a single permissive callback can undermine otherwise strong transport protections.

For a broader view of secure WebView handling, the Mobile WebView Security Guide covers TLS errors, load restrictions, and bridge hardening in the same execution environment.

Detection and remediation after a bad decision

If an app has been allowing loads after certificate errors, review whether sensitive pages were exposed to interception or tampering. Look for suspicious navigation paths, unexpected certificate prompts, or code paths that always return a permissive decision in the callback. After deployment, test the app’s behavior against invalid, expired, self-signed, and mismatched certificates to confirm the failure path is actually enforced.

When the issue is systemic, remediation usually means removing permissive handling, tightening the app’s TLS policy, and verifying that the app still fails closed under network manipulation. The companion OWASP Mobile Top 10 M5 Insecure Communication Guide explains the broader mobile communication failures that this callback can amplify, including weak certificate handling and man-in-the-middle exposure.

Risk and Threat Considerations

Allowing a WebView to continue after an SSL/TLS certificate error creates a direct man-in-the-middle opportunity. The threat is not theoretical: once the app accepts an invalid certificate, an attacker who can intercept traffic may be able to observe or modify sensitive web content, capture credentials, or persist inside the session.

Failure mechanism: A permissive callback converts certificate validation from a hard security control into a bypassable warning, which makes interception and content tampering far easier.

Impact: Sensitive WebView traffic can be exposed, user sessions can be hijacked or altered, and any downstream trust placed in the loaded page becomes unreliable.

Practitioner Guidance

Governance implication: Treat this callback as a security policy decision, not a convenience hook. Applications that load sensitive content should default to fail closed, and any exception path should be limited, reviewed, and justified at the code and release level.

Practitioner takeaway: If you cannot explain why a certificate error is safe to ignore in a specific environment, the correct response is to abort the load.