Security model · Last reviewed 24 August 2026
Claims should follow evidence.
This page describes the controls implemented today and the boundaries users still need to manage.
- Browser encryption
- The sender’s browser generates a random 256-bit master key and encrypts text or file bytes with AES-256-GCM before upload. Optional passphrases are combined with that key through PBKDF2-SHA-256 using 250,000 iterations and a random salt.
- Key separation
- The master key is encoded after the URL
#. Browsers do not include URL fragments in ordinary HTTP requests, so the application server receives the opaque record identifier but not that key. - Stored material
- The server stores ciphertext, an encryption nonce, a derivation salt, expiry metadata, and whether a passphrase is required. Records expire after at most seven days and are stored with restrictive file permissions.
- One-time retrieval
- Availability checks do not consume a record. An explicit confirmation POST atomically renames and claims it before returning ciphertext, then removes the claimed file. Concurrent requests cannot both claim the same source record.
- Operational controls
- Request bodies and files have size limits, API requests are rate-limited in the application and deployment proxy, responses use no-store where appropriate, and the server sends CSP, frame, MIME-sniffing, referrer, and permissions headers.
- Limitations
- SecretShare cannot protect a compromised browser, malicious extension, unsafe recipient device, copied link, screenshot, clipboard history, recipient forwarding, or a deployment account that changes delivered JavaScript. File storage supports a single application instance only.
- Recommended use
- Use one-time links for temporary bootstrap and exceptional handoffs. Prefer individual identities, password managers, workload identity, short-lived credentials, and rotation for ongoing access. Do not use the service for emergencies or as the only copy of irreplaceable information.
- Disclosure
- Report potential vulnerabilities privately to security@secretshare.dev. Include impact and reproducible steps, but never include real credentials or access data you do not own.