Zero-knowledge encryption
fetchOnce is architected so the server never has access to your secret values. All encryption and decryption happens in your browser using native cryptographic APIs. The server stores only opaque ciphertext it cannot read. The encryption key exists only in the URL fragment, which browsers never transmit to servers.
Encryption details
fetchOnce uses AES-256-GCM, an authenticated encryption algorithm that provides both confidentiality and integrity. Each secret gets a unique 256-bit key generated by the browser's cryptographically secure random number generator. The ciphertext includes a randomized 96-bit initialization vector and a 128-bit authentication tag that detects any tampering with the encrypted data.
Transport security
The encryption key is carried in the URL fragment (the part after #). Per the HTTP specification, fragments are never sent to the server in requests. This means the key never appears in server logs, proxy logs, or network traffic to the backend. In production, TLS encryption protects the full connection between the browser and the edge.
Infrastructure
The application runs behind a hardened reverse proxy, communicating with the backend over a local socket rather than a network interface. This eliminates network-level attack surface between the proxy and application layers. The proxy enforces security headers including content security policies, transport security, frame protection, and content type enforcement.
Encryption at rest
The stored data is AES-256-GCM ciphertext that cannot be decrypted without the key from the URL. Secrets are permanently deleted from the database upon reveal or expiration via an atomic transaction — the read and delete happen together, so a second request finds nothing. There is no soft-delete, no recycle bin, and no backup retention of secret content.
Responsible disclosure
If you discover a security vulnerability in fetchOnce, please report it responsibly. We take all reports seriously and will respond promptly.