clipboard-guard

The feature looks like a UI convenience — a copy icon next to a password field, an OTP that auto-fills once pasted — but the OS clipboard is a store with its own retention, its own history UI, and on several platforms its own sync fabric to other devices. The moment the app writes a secret to it, that secret is now held by a system the app doesn't control and has no built-in way to recall. "We put a copy button there" is the easy part; whether anything ever takes that copy back is a separate question almost nobody asks.

The case that makes this concrete: Apple's iOS 14 clipboard-access notification (2020) surfaced that dozens of major apps — TikTok, LinkedIn, Reddit, and others, widely reported at the time — were reading the general pasteboard on nearly every keystroke or app-foreground transition, not only when a user actually pasted. None of it was a deliberate secret-stealing exploit; it was background code with no gate on why it was reading, catching whatever happened to be on the clipboard at that instant, including passwords and codes the user had copied for something else entirely. Separately, Android/Samsung cross-device clipboard sync and Windows' Cloud Clipboard (Win+V history, roams via a Microsoft account when enabled) both persist and can propagate a copied value to a second device or a visible history list well after the app that wrote it believes the value is gone. The shape to hunt for is the same in both directions: not "does the copy button work," but "what can read this clipboard, when, and can anything that's already been copied actually be un-copied."

Step 1: enumerate every clipboard write and read in the feature under review

List every place the app explicitly writes to the clipboard (a "copy" action next to a password, an OTP/2FA code, a card or bank account number, an API key, a recovery/backup code, a session or magic-link token) — and separately, every place it reads the clipboard rather than only writing it (an OTP field that auto-pastes, a "clipboard watcher" that polls for a verification code sent out-of-band). For each write, note whether the value belongs to the sensitive categories above; a copy-to-clipboard button on a public share link or a non-secret ID isn't this skill's concern.

Step 2: for each sensitive write, check whether it's ever taken back

Two independent layers matter, and a fix at only one still leaves a gap:

• App-side clear. Does the app clear the clipboard itself after a short timeout, or once the value has been pasted once, or does the copied value just sit there until the user happens to overwrite it by copying something else? No clear-timeout at all, for a short-lived high-value secret like an OTP or magic-link token, is a real and common gap.
• Platform-side flag. iOS and Android both let a copy be marked so the OS itself keeps it out of cross-device sync and clipboard-history UIs — UIPasteboard's expirationDate/localOnly options on iOS, ClipDescription.EXTRA_IS_SENSITIVE on Android. Using the plain copy API without this flag means the value is a candidate for Universal Clipboard / Nearby Share propagation and for any clipboard-history manager's persisted list, regardless of how fast the app's own timeout fires — an app-side clear a few seconds later doesn't retract a copy that already synced to a second device or landed in a history entry in the first second. Check for the flag explicitly; its absence is a fixable gap, not a platform limitation.

Step 3: check whether any clipboard read is gated on an explicit paste

For anything found in Step 1 that reads the clipboard, confirm the read only happens in direct response to a user-initiated paste action (a tap on a "paste" button, a focused paste event), not unconditionally on a timer, on every keystroke, or on every app-foreground transition. The 2020 iOS wave happened precisely because apps read on "did the app just come to the foreground," not "did the user ask to paste" — an unconditional read is exposure even when the app never transmits what it read anywhere, because it's needlessly touching values it had no reason to handle, including whatever secret another app happens to have put there for an unrelated purpose.

Step 4: name the hard boundary — what's already out of reach

Once a sensitive value has been written to the general clipboard without the platform's sensitive/expiring flag, cross-device sync (iOS Universal Clipboard, Android Nearby Share/Samsung Flow, Windows Cloud Clipboard roaming) and any third-party clipboard-manager app running on the device can have already taken their own copy before the app's own clear-timeout ever fires — sync and history-capture both typically happen immediately on write, not after some delay. State this plainly rather than implying a 30-second app-side clear is a complete fix for a value that may have already propagated to a second device, or into a visible history list, within the first second it existed. The only real mitigation at that point is not using the unflagged general clipboard for the value in the first place (an in-app secure field, a password-manager API, a one-tap "fill" that never materializes the plaintext on the OS clipboard at all).

Report

Lead with the worst confirmed gap. BLOCK for: a short-lived high-value secret (OTP, magic-link token, recovery code) written to the clipboard with neither an app-side auto-clear nor the platform's sensitive/expiring flag set; or the app reads the clipboard unconditionally (on keystroke, on timer, or on every foreground transition) rather than only on an explicit user-initiated paste. CAUTION for: a sensitive value is cleared app-side but without the platform sensitive/expiring flag, so it's still exposed to cross-device sync or a history manager during the window before the clear fires; or the clear window is long enough to meaningfully overlap realistic shoulder-surfing or sync-propagation timing. SAFE only with evidence: either no sensitive value ever touches the general clipboard (autofill happens through a password-manager API or an in-app secure field instead of copy/paste), or every sensitive copy uses the platform's sensitive/expiring API and is cleared promptly app-side too, and every clipboard read in the feature is gated on an explicit paste.

Boundaries

• Not security-sweep's territory alone — security-sweep's sensitive-data-exposure line item is a generic checklist bullet inside a broad diff review; this skill is the dedicated walk of one specific mechanism (what leaves through the OS clipboard, and whether it's ever actually taken back), with more depth than a single bullet gives it.
• Not secret-spill's territory — secret-spill is incident response for a credential already committed to git history or leaked into CI logs. This is a pre-emptive audit of a live clipboard write/read path in application code, not remediation after an exposure has already happened.
• Can't verify what a specific OS version, third-party clipboard-manager app, or a user's own cross-device sync settings actually retain or display from source code alone — platform behavior shifts across versions, and whether cloud clipboard sync is even enabled is a user setting, not something the app's code determines. State what the code does and what the platform API allows; don't assert certainty about a live device's current clipboard contents without the user confirming device-level settings.
• Doesn't audit clipboard handling inside code the app doesn't control — a password manager's own browser extension, the OS clipboard subsystem itself, or a third-party SDK's opaque copy call are out of scope beyond flagging that the app under review hands them a copy.