Application Security

Clipboard and Rich-Text XSS Treat Pasted HTML as Hostile

Handle text/plain, text/html, images, and custom clipboard types with plain-text defaults, sanitization, Trusted Types, and validation on both peers.

Before shipping it, separate protocol facts, product promises, and operating cost. Mixing those layers produces confident but incorrect decisions. Clipboard HTML can contain event handlers, dangerous URLs, SVG, and browser-specific markup. Crossing devices creates a new trust boundary even for user-owned content.

Security review starts with assets, attacker capability, and trust boundaries, then reauthorizes every state transition. Validation, rate limits, and audit complement rather than replace authorization.

The parts that make the design practical

This capability crosses clients, networks, and servers, so a local optimization can create a system failure. Decisions must constrain both endpoints, persisted truth, and operating budgets together.

  • Default to plain text; when formatting is required use a mature allowlist sanitizer, remove scriptable URLs, style leaks, and unknown namespaces, then enforce Trusted Types.
  • Bound every input by size, count, and time, returning a stable actionable error code when a budget is exceeded.
  • Ship conservative defaults, server-side ceilings, and a rollout switch instead of trusting browser-provided numbers as resource budgets.

The delivery standard for Clipboard and Rich-Text XSS Treat Pasted HTML as Hostile is a usable normal path, convergent failures, bounded resources, and a state users can understand. The result is a production capability that can be explained, degraded safely, and rolled back—not a demo that works once.

Keep false assumptions out of production

Production failures often appear when two individually valid actions overlap. Inspect stale messages, duplicate effects, exhausted resources, and mixed versions instead of patching only the current stack frame.

  • Removing script tags by regex misses img onerror, SVG animation, and javascript URLs, while sender-only sanitization trusts a modifiable client.
  • Refresh and network change start two recovery paths, and duplicate side effects look like two genuine user actions.
  • Without backpressure or quota, a slow consumer raises memory, queue depth, and tail latency until unrelated users are affected.

What the release gate should inspect

Build golden cases from known inputs and controlled faults, then align production metrics with those results. Verification extends to production only when signals detect the same degradation early.

  1. Transfer XSS polyglots, nested SVG, malformed HTML, huge rich text, and plain-text fallbacks across browsers; no executable DOM node may survive.
  2. Drive the state machine with reordered, duplicate, and delayed messages, proving stale versions are ignored and explicit stop survives recovery.
  3. Use fault injection to prove alerts precede user reports and operators can locate the failing phase from bounded evidence.

The release bar is clear: users understand the current state, failures stop or recover, resources stay bounded, and operators can identify the phase from minimum necessary evidence.

Put the guide to work

Open uCopy and connect two devices securely from the browser.

Start for free