Share sensitive information through encrypted links that automatically expire after a configurable number of views or a specified duration.
 Create |
 Share link / code |
 Reveal |
 Destroyed / expired |
 Mobile |
Traditional messaging platforms store your messages and often have access to plaintext content.
SecretSend takes a different approach:
- Encryption happens entirely in your browser.
- Decryption happens entirely in your browser.
- Encryption keys never reach the server.
- Secrets can automatically expire.
- Secrets can self-destruct after a limited number of views.
- Secrets can be shared via a link, a 6-digit code, or both.
The backend stores only encrypted ciphertext.
Even if the database is compromised, attackers cannot recover the original secret without the encryption key.
Uses AES-GCM through the browser's Web Crypto API.
Automatically delete secrets after:
- 1 view
- Multiple views
- Configurable limits
Expiration options range from 1 minute up to 1 day.
Encryption keys are stored in the URL fragment:
https://example.com/s/secret_id#encryption_key
URL fragments are never sent to the server.
For cases where a link can't be sent, a secret can instead be unlocked with a server-generated 6-digit code:
- The code is generated by the server's CSPRNG — never chosen or influenced by the client.
- The encryption key is wrapped client-side (PBKDF2 + AES-GCM) using the code before it ever reaches the server.
- Redeeming a code shares the same view budget as the link, and both are rate-limited against guessing.
- Intentionally the weaker of the two sharing methods (a 6-digit code has far less entropy than the link's embedded key) — meant as a fallback, not a replacement for the link.
Responsive design supporting:
- Phones
- Tablets
- Desktops
Redis provides near-instant secret access.
┌───────────────┐
│ User │
└───────┬───────┘
│
▼
┌──────────────────┐
│ React Frontend │
│ Web Crypto API │
└───────┬──────────┘
│
Encrypt│Decrypt
│
▼
┌──────────────────┐
│ FastAPI Backend │
└───────┬──────────┘
│
▼
┌──────────────────┐
│ Redis │
└──────────────────┘
| Component | Can See Plaintext? |
|---|---|
| Browser | ✅ Yes |
| FastAPI Backend | ❌ No |
| Redis Database | ❌ No |
| Backend VM Host | ❌ No |
| Vercel Hosting | ❌ No |
Additional server-side hardening: per-IP rate limiting (keyed off the raw TCP peer address, not a client-suppliable header, so it can't be spoofed), a locked-down CORS allowlist, a request body size cap enforced ahead of parsing, request/TTL caps, and a Redis memory ceiling with LRU eviction so no single client can exhaust the backend's resources.
- React
- Vite
- React Router
- Web Crypto API
- FastAPI
- Uvicorn
- Redis
- Vercel (frontend, proxies API requests to the backend)
- Docker Compose (FastAPI + Redis)
- Oracle Cloud Free Tier (backend VM)
- End-to-end encryption
- One-time secret retrieval
- Expiration system
- View limits
- Mobile-responsive UI
- Cloud deployment
- Code-based sharing (server-generated 6-digit codes)
- Rate limiting and abuse hardening
- Password-protected secrets
- Split-key sharing mode
- File sharing
- QR-code sharing
- Secret folders
- Access analytics
- Temporary encrypted notes
- Shamir Secret Sharing
- Progressive Web App (PWA)
This project explores:
- Applied Cryptography
- Secure Software Design
- Client-Side Encryption
- FastAPI Development
- Redis Data Management
- React Frontend Architecture
- Cloud Deployment
- End-to-End Encryption Systems
Contributions, feature requests, and bug reports are welcome.
- Fork the repository.
- Create a feature branch.
- Commit your changes.
- Open a pull request.
MIT License
Feel free to use, modify, and learn from this project.
Abdul Rafay
CS student at ITU and AI Engineer working on AI automation, computer vision, and backend systems.
- LinkedIn: linkedin.com/in/abdurafay19
- GitHub: github.com/abdurafay19
Built with React, FastAPI, Redis, and curiosity.