The system clipboard is a global, cross-app channel, and a WebView page can read everything your user copied — payment cards, passwords, one-time passcodes. On Android the clipboard was readable by any background app before Android 10 and only gained an access toast and a sensitive-data flag in Android 12. On iOS the general pasteboard is system-wide, persists across restarts, and syncs across devices via Universal Clipboard; iOS 14 added a read notification and iOS 16 a paste prompt. But the web read path inside a WebView is untouched by those native mitigations: a page with clipboard access and a user gesture can harvest credentials the app just copied for the user. A host-owned runtime mediates the clipboard at the native layer — marks sensitive items localOnly with expiration, and gates web reads behind explicit user intent.
The clipboard was a global eavesdrop
Android's clipboard is a framework for copying and pasting data between applications, and a poor implementation exposes user data to other apps (Android Developers, OWASP MASVS-CODE). The exposure varies by version: before Android 10, background apps could read the foreground app's clipboard silently — any copied password, OTP, or card number was available to a malicious app. From Android 12, the system shows a toast every time an app accesses the clipboard, and developers can flag sensitive data with EXTRA_IS_SENSITIVE to obfuscate the preview in the keyboard UI. That helps native writes, but it does nothing for what a web page reads.
iOS makes it persistent and synced
On iOS, the general pasteboard is shared across all foreground apps and, since iOS 10, synced to nearby Apple devices through Universal Clipboard; it persists across restarts and app reinstalls unless cleared (OWASP MASTG-KNOW-0083). Since iOS 14 the system notifies the user when an app reads pasteboard content written by a different app, and since iOS 16 it prompts for paste confirmation. Named pasteboards are app- or team-scoped, but most apps just use the general one. The permission prompt is also a tax: e-commerce apps that read the clipboard at launch to detect copied product links now spam the user with paste prompts — and detectPatterns can still reveal that the clipboard resembles a URL, number, or phone without returning its value.
Inside a WebView, the web reads it too
Here is the part the OS mitigations miss. A WebView page can call the Clipboard API or execCommand('paste') with a user gesture and read whatever the user copied. Combine that with the autofill and OTP-auto-read patterns already common in hybrid apps, and a malicious or compromised catalog page becomes a credential harvester: the user copies a one-time passcode to log in, the page reads it, and the session is gone. The native EXTRA_IS_SENSITIVE flag protects what your app writes, but the web page's read is governed by the same browser clipboard rules — and a WebView does not enforce the host's intent the way a native screen would. The clipboard, meant as a convenience, becomes a back door that the platform's own privacy controls do not close.
The runtime fix
A host-owned runtime mediates clipboard access at the native layer instead of leaving it to the page. Sensitive items are written localOnly with an expirationDate so they never reach Universal Clipboard or survive a reboot. Web clipboard reads are gated behind explicit user intent — a visible paste control, not a silent read — and untrusted catalog entries are denied clipboard access entirely. The convenience stays; the back door closes.
| Dimension | WebView | Host-owned runtime |
|---|---|---|
| Clipboard scope | Global, cross-app, on iOS synced + persistent | Native-layer mediated, localOnly + expiry |
| Background read | Pre-Android 10 silent; toast from 12 | Host gates every web read |
| 2FA / OTP exposure | Copied code readable by any page | Untrusted entries denied; intent-gated |
| Web read path | Clipboard API on a gesture, untouched | Visible paste control, no silent read |
| Native mitigation gap | EXTRA_IS_SENSITIVE helps writes only | Covers both writes and web reads |
The series keeps returning to the same lesson: a WebView inherits the platform's weakest surfaces and adds a web-shaped one. The clipboard is a convenience that, in a WebView, becomes a cross-app and cross-page eavesdrop the OS cannot fully close. A runtime puts the host between the page and the clipboard — so the convenience is the app's, and the exposure is not.
Sources
- Android Developers — Secure Clipboard Handling (MASVS-CODE): global clipboard, pre-Android 10 background reads, EXTRA_IS_SENSITIVE flag, toast on access from Android 12 — the native side of clipboard exposure and its mitigations.
- OWASP MASTG-KNOW-0083 — Pasteboard: iOS general pasteboard is system-wide, persistent, Universal Clipboard sync, iOS 14 notification, iOS 16 paste prompt — why iOS clipboard is a cross-device, cross-app surface.
- Web.dev — Web on Android: WebView gives the embedding app full access to rendered content and lacks the browser's security UI; relevant to clipboard and DOM exposure — the structural gap between WebView and a hardened browser.
- Juejin — iOS 16 paste permission changes: apps that read the clipboard at launch now spam paste prompts; how to avoid the dialog — the UX tax of unmanaged clipboard reads.
- HackTricks — iOS UIPasteboard: detectPatterns discloses metadata without returning value; localOnly and expirationDate guidance — the metadata oracle and hardening options.
