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.
| Mode | Discoverable | Who can open | Server holds plaintext? |
|---|---|---|---|
| Public | No public listing UI — anyone with the URL | Anyone | Yes, unless also client-encrypted |
| Unlisted | No intentional listings | Anyone with the public id / URL | Yes, unless also client-encrypted |
| Private | No | Owner only (session or API key) | Yes, unless also client-encrypted |
| Password | No intentional listings | Anyone who knows the paste password | Yes after successful password check, unless also client-encrypted |
| Client-encrypted | Follows base visibility | Same ACL on ciphertext | Never — 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 should send
X-Paste-Password(preferred over putting secrets in query strings). - 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.
- 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 create for non-client-encrypted content. It is not a guarantee.
- Rate limits (Redis) apply per IP, user, or API key.
Limits
VoidPaste is free. There is no paid tier. Each paste is limited to 1 MB (1,048,576 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.