A zero-knowledge, end-to-end encrypted secret sharing platform that enables secure transmission of sensitive information.
- 🔒 End-to-end encryption using AES-256-GCM
- 🔒 Strict Content Security Policy (CSP) to prevent XSS attacks and unauthorized resource loading
- 🔒 Strict rate limits to mitigate brute-force attacks
- 🤫 Zero-knowledge architecture - server never sees unencrypted data or decryption keys
- 🔥 Burn after reading w/ provisions to prevent erroneous burns from bots or url introspection
- ⏰ Automatic expiration (Time-To-Live)
- 🔑 Password protection
- 📁 File sharing support w/ drag and drop
- 🪝 Webhook notifications for read success, read failure, and burn events
- 🌐 IP/CIDR allow-listing
- 🔢 Read count limits
- 📱 QR code generation
- ⌨️ CLI for interacting with the API
- 🐳 Docker images for the api server and web client
- 🌐 Localization with a handful of supported languages (more to come - help wanted!)
- Encryption key is generated on the client
- Password is optionally provided
- Encryption key and password are used to encrypt the secret
- Encryption key and password are hashed and stored along with the encrypted secret for verification on retrieval - the raw key and password are never stored or transmitted on/to the server
- The unique URL containing the decryption key is generated on the client
- Share the URL with your recipient and separately the password if specified
- When accessed, only when the decryption key and password match via server-side verification of the hashes, the encrypted secret is shared and decrypted in the recipient's browser
- Optionally, the secret is automatically destroyed after being read in an atomic read & delete operation guaranteeing only one person can access the secret
- If retrieval doesn't happen within the TTL, the secret is automatically destroyed
- React SPA
- shadcn/ui
- Node.js with Fastify
- Redis
- Web Crypto API
- OpenTelemetry
- Clone the repository
- Install dependencies:
yarn install
- Set up environment variables (see
.env.example
) - Start the development server:
yarn run dev
- The toast notification library (sonner) requires specific style-src hashes in the CSP configuration
- These hashes are defined in
nginx/nginx.conf
- Updates to sonner may require updating these hashes
- Reference: sonner#449
- Ensure Redis is running locally when developing the server
- The web client expects the API to be available at
http://localhost:4321
by default - CSP headers in development may differ from production configuration
- Always test encryption/decryption flows thoroughly when making changes
- Ensure no sensitive data is logged or exposed in error messages
- Maintain strict CSP headers to prevent XSS vulnerabilities
- Keep dependencies updated for security patches
Contributions are welcome! Please feel free to submit an Issue or Pull Request on GitHub.