Security
What we hold, what we cannot hold, and what an attacker would get.
What the server sees
Ciphertext, a size, an expiry, a view counter, and the timings of what happened. Not the content, not the filename, not the type, and never the key.
Where the key lives
In the link, after the '#'. Browsers do not send that part to a server, and neither do we: it is generated in your browser and used there.
The envelope
AES-256-GCM with a key derived through HKDF-SHA-256, streamed in 1 MiB chunks with per-chunk nonces so a truncated file cannot be passed off as a whole one. A passphrase adds PBKDF2-SHA-256 at 600,000 iterations, split so the server holds a verifier and never the key half.
Exactly once
A view is consumed by a single conditional UPDATE that returns the payload. Two people clicking at the same moment cannot both win, and the loser is told the secret is gone rather than handed a copy.
curl mode
Your terminal cannot run our code, so that one path encrypts on our server. Every response says so, and the interstitial shows it as a badge. The CLI does not: it encrypts on your machine.
What an attacker gets
With our database: ciphertext and timings. With our logs: no bodies on secret paths, an allowlisted set of headers, and a redaction test that fails the build on a leak. With the link: everything, which is why the link is the secret.
Reporting a vulnerability
security@secretpaste.com, or the address in /.well-known/security.txt. We answer within one business day and we do not threaten researchers.