Separate trusted and untrusted content
List the origins your WebView needs. Treat redirects, embedded frames and user-provided links as part of the navigation surface. Checking whether a URL string merely contains your domain is not a safe origin check.
Parse the URI and compare the expected scheme and host. For sensitive integrations, consider port and path rules as well. Do not accept trusted.example.attacker.test because it contains a familiar substring.
Minimize native bridges
The Android WebView security guidance describes risks from JavaScript-to-native bridges. Expose only the smallest necessary interface, and do not attach a privileged bridge to content outside your control.
| Bridge capability | Safer design question |
|---|---|
| Read local files | Can the feature use an explicit, narrowly scoped result instead? |
| Execute arbitrary actions | Can native code expose one validated operation? |
| Return account tokens | Can authentication remain in a safer dedicated flow? |
| Open supplied URLs | Are scheme, host and destination checked? |
A bridge method's name does not constrain what hostile input can request if the implementation accepts arbitrary commands or paths.
Handle navigation deliberately
Decide which links stay in the WebView and which open in an external browser or a dedicated authentication flow. Never bypass TLS errors to make a page load. Review file access, mixed content and debugging settings for the release build rather than inheriting development defaults.
Test hostile inputs in your own app
Use controlled pages to test unexpected origins, redirects, malformed URLs and missing messages. Confirm that the native side rejects unauthorized requests even when the web interface normally hides the corresponding button.
Test logout and account changes too. Cached web content should not preserve access to a previous user's sensitive state.
Use static findings as leads
APKLint can identify manifest and code indicators relevant to WebView review, but it cannot enumerate every page your server may deliver or prove the origin-validation logic is correct. Combine static inspection with runtime tests of the actual content and native bridge contract.
Avoid giving a help page account-level native powers
Suppose an app embeds a support page and adds a bridge method to open a native settings screen. Define that single action explicitly. Do not expose a general command dispatcher, arbitrary file reader or account-token getter simply because the page might need more features later. A narrow bridge contract reduces what a compromised or unexpectedly loaded page can request.
The native-bridge guidance explains that a JavaScript interface can be available to frames within the WebView. Checking only the initial top-level URL does not establish that every frame calling the bridge has the same trust. Consider whether the feature can avoid a bridge entirely.
Test navigation after the trusted first page
Use controlled pages to navigate from the intended support origin to another origin, follow a redirect and embed an unexpected frame. Verify the application's policy at each transition. A WebView that started safely can later contain different content, so privileged capabilities must not remain available merely because the first load passed a check.
Test malformed and unsupported bridge messages as well as the documented message. Native code should validate the operation, arguments and current account state independently of the web page's visible buttons. Hiding a button from a logged-out user does not stop script from attempting the corresponding call.
Exercise logout while the page remains open, then switch to another synthetic account. Confirm that cached content and pending callbacks do not expose the earlier account's information. If the screen must reload or close to enforce the new state, make that transition explicit and verify that back navigation does not reopen a privileged stale page.
Include a certificate-error case on a controlled test endpoint and confirm that the app does not proceed past it. Keep the release settings for debugging, file access and mixed content in the same review. The useful result is a documented boundary around content and native operations, supported by navigation and lifecycle tests, rather than a claim that enabling HTTPS alone makes every WebView interaction safe.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
