Security model and privacy controls

What we implement, what each privacy mode means, and what we do not claim.

This page summarizes product security behavior. It is not a certification, audit report, or compliance attestation. We do not claim SOC 2, ISO 27001, HIPAA, or similar unless a separate formal report says so.

Report a vulnerability

Prefer email: [email protected]. Machine-readable contact: /.well-known/security.txt. Please include steps to reproduce and avoid testing that harms other users' data.

Threat model (honest)

  • You trust our servers for non-client-encrypted pastes: we store plaintext (or password-gated plaintext after check) and can read it in principle.
  • You trust our JavaScript for client-side encryption: a compromised web origin or malicious extension can steal keys or plaintext in the browser.
  • URL secrecy is fragile: unlisted and share links leak via chat logs, history, referrers, and screenshots.
  • Operators and infrastructure (hosting, backups, logs) can access server-side data for pastes that are not client-encrypted.

Visibility modes

Paste visibility and client-side encryption are different controls. Encryption can compose with any base visibility.

Paste visibility and encryption comparison
ModeDiscoverableWho can openServer holds plaintext?
PublicNo public listing UI — anyone with the URLAnyoneYes, unless also client-encrypted
UnlistedNo intentional listingsAnyone with the public id / URLYes, unless also client-encrypted
PrivateNoOwner only (session or API key)Yes, unless also client-encrypted
PasswordNo intentional listingsAnyone who knows the paste passwordYes after successful password check, unless also client-encrypted
Client-encryptedFollows base visibilitySame ACL on ciphertextNever — ciphertext only; keys are not stored on the server

Unlisted is secrecy-by-URL, not an access-control list. Anyone who obtains the link can read an unlisted paste (or its ciphertext). Private requires authentication as the owner.

Burn after reading

  • On the first successful authorized view, the API marks the paste burned and returns content in that response (burned: true).
  • Later requests return gone/not found after cleanup. There is no "undo" from support.
  • Share burn links only with the intended first reader.

Password-protected pastes

  • Paste passwords are separate from account passwords.
  • Stored as argon2id on the paste when visibility=password.
  • Clients send X-Paste-Password. The API does not accept the password on the query string.
  • Attempts are rate-limited independently of account login.

Client-side encryption

  • Algorithm: AES-256-GCM in the browser (Web Crypto).
  • Random key material is carried in the URL fragment (#…) so it is not sent to the server on HTTP requests, or derived from a user password via PBKDF2-HMAC-SHA256 (310,000 iterations) with a salt.
  • The server stores ciphertext and metadata flags only — not AES keys, fragments, or paste encryption passwords.
  • The API accepts the encryption flag only with the versioned VoidPaste envelope (AES-256-GCM, canonical base64url ciphertext, and bounded IV/KDF parameters). This verifies format, not that an arbitrary caller encrypted meaningful plaintext; generic safeguards and rate limits still apply.
  • Lost keys cannot be recovered by VoidPaste support. Treat share links (and passwords) as credentials. Browser history, extensions, and screenshots can leak fragment keys.
  • You still trust the JavaScript we serve; this is not a substitute for end-to-end messaging with independent client verification.

Account authentication

  • Account passwords hashed with argon2id.
  • Session cookies: opaque token client-side; SHA-256 hash server-side; HttpOnly; Secure in production; SameSite=Lax.
  • API keys: vp_live_… / vp_test_…, hashed at rest, scoped, revocable.

Content handling

  • Paste bodies are untrusted. UI rendering escapes content; raw endpoints are text/plain with nosniff.
  • Best-effort secret detection may warn or block on every submitted representation. Real ciphertext is opaque, so detection on it is not a guarantee.
  • Rate limits (Redis) apply per IP, user, or API key.

Where enforcement happens

Security boundaries are enforced by the API and reverse proxy, including authorization, CSRF validation, trusted client IP handling, rate limits, content handling, and response headers. VoidPaste does not block page access behind browser verification or treat client capability checks as a security control.

Signed-in accounts without a verified email are read-only. The API blocks account writes, API-key writes, security-setting changes, moderation, and administration on every request, including requests made with an existing API key. Anonymous paste creation remains available only through an explicit anonymous choice and uses anonymous ownership and limits.

Limits

VoidPaste is free. There is no paid tier. Anonymous pastes are limited to 1 MB (1,048,576 bytes); signed-in accounts and API keys allow 5 MB (5,242,880 bytes). Rate limits apply to creation and reads. Those limits are abuse controls, not a paid plan.

What we do not claim

  • No claim of formal security certifications on this page.
  • No claim that unlisted or password pastes are immune to link leakage.
  • No claim that client encryption survives a compromised browser or malicious extension.
  • No claim that secret detection finds every secret.
  • No claim of permanent deletion timing SLAs beyond implemented cleanup workers.

Related: Privacy, Acceptable use, API.