How it works
CryptBin security architecture
CryptBin is designed so your backend stores encrypted payloads and metadata, while decryption happens in the browser. The decryption key is carried in the URL fragment and is not sent in standard HTTP requests.
Security guarantees at a glance
What we protect
- Plaintext is encrypted before upload.
- The API stores ciphertext, IV, and retention metadata.
- Key fragment stays client-side in the URL hash.
What we do not protect
- Compromised endpoint devices or browsers.
- Users sharing full URLs in unsafe channels.
- Secrets exposed before encryption (clipboard/history).
Operational controls
- Expiration windows for automatic invalidation.
- Burn-after-read for single-read workflows.
- Vault-backed fragment recovery for signed-in users.
Create lifecycle
- Compose
Author content and choose expiration / burn-after-read policy.
- Encrypt in browser
The client derives/generates key material and encrypts content before network transfer.
- Upload ciphertext
Only encrypted payload, IV, and metadata are sent to the API layer.
- Return share URL
The final URL combines a server-side ID with a hash fragment that contains decryption material.
Threat model boundaries
Server compromise scenario: an attacker that only gets database access sees ciphertext and metadata, not plaintext keys.
Client compromise scenario: if an attacker controls the endpoint, plaintext and fragments can be exposed. Endpoint hygiene remains critical.
Link-handling scenario: sharing full URLs grants access; fragment secrecy is only as strong as your transport channel.
Operational notes
- Loss of fragment means loss of decryptability for that link.
- Vault password enables cross-device recovery of supported links.
- Audit usage with retention policy aligned to data sensitivity.
- Prefer short expirations for high-risk data categories.
