Security model

Last updated: 27 August 2026

paste is zero-knowledge: your text is encrypted in your browser and the server only ever holds ciphertext. Here is precisely how that works and what it does and does not protect.

How encryption works

• A random AES-256-GCM key is generated in your browser.
• The text is encrypted locally; only the ciphertext and IV are uploaded.
• The key is placed in the link fragment (#…), which browsers never send to a server.
• GCM's authentication tag means a wrong key or tampered ciphertext fails loudly instead of returning garbage.

What the server can and cannot see

It sees ciphertext, size, timestamps and the TTL. It never sees your plaintext or the key, and it cannot decrypt a paste. A network attacker over TLS sees only ciphertext.

Is stored content dangerous?

No. A paste is inert data. The server never executes it, and the reader renders it as text, so a pasted script or reverse-shell one-liner is displayed, not run. There is no innerHTML and no eval, and a strict nonce-based Content-Security-Policy (no unsafe-inline in script-src) blocks injected scripts as a second layer.

Controls

• Burn after reading: deleted on first retrieval.
• Auto-expiry: every paste has a TTL and is removed when it lapses.
• Deletion token: the creator gets a one-time token (only its hash is stored) to delete a paste early.
• 200 KB size cap, per-IP rate limiting, unguessable random ids, strict security headers.

Honest limits

• Metadata such as ciphertext size and timing is visible to the server.
• Because pastes are encrypted, content cannot be moderated; abuse is handled by expiry, limits and takedown.
• As with any web app, you trust that the code served to your browser matches the public repository.

Report an issue

security@0x6a03448f4d.com — see also /.well-known/security.txt.