Back to Guides

One-Time Link Security: How It Works

A deep dive into the cryptographic principles that make one-time links secure for sensitive data.

When you create a one-time link for sharing sensitive information, there's a lot happening under the hood. This guide explains the cryptographic principles and security architecture that make one-time links a secure method for sharing passwords, API keys, and other sensitive data.

The security model

One-time link security is built on three core principles:

  1. Client-side encryption: Data is encrypted in the user's browser before being transmitted to the server.
  2. Zero-knowledge storage: The server only stores encrypted data it cannot decrypt.
  3. Automatic destruction: Data is permanently deleted after being accessed or when it expires.

AES-256-GCM encryption

Burn the Secret uses AES-256-GCM (Advanced Encryption Standard with 256-bit keys in Galois/Counter Mode) for encrypting secrets. This is the same encryption standard used by governments and financial institutions for classified and sensitive data.

256-bit key strength. A 256-bit key has 2^256 possible combinations. Even with all the computing power on Earth, brute-forcing this would take longer than the age of the universe.

Authenticated encryption. GCM mode provides both confidentiality and authenticity. If anyone tampers with the encrypted data, decryption will fail, detecting the modification.

Web Crypto API native. AES-GCM is natively supported by the Web Crypto API, meaning encryption happens securely in the browser without external libraries.

The encryption process

Here's exactly what happens when you create a one-time link:

Step 1: Key generation. A random 256-bit encryption key is generated in your browser using the Web Crypto API's cryptographically secure random number generator.

Step 2: Encryption. Your secret is encrypted using AES-256-GCM with a random initialization vector (IV). The IV ensures that encrypting the same data twice produces different ciphertexts.

Step 3: Server storage. Only the encrypted ciphertext and IV are sent to the server. The encryption key stays in your browser.

Step 4: Link generation. The encryption key is placed in the URL fragment (after #). URL fragments are never sent to servers—they only exist in the browser. The final URL looks like: burnthesecret.com/secret/abc123#key=3Kd8f... but the server only sees: burnthesecret.com/secret/abc123

Zero-knowledge architecture

The URL fragment mechanism is the key to zero-knowledge security. According to the HTTP specification, everything after the # symbol in a URL is handled client-side only. It's not included in HTTP requests to the server, doesn't appear in server logs or analytics, isn't visible to network intermediaries (proxies, CDNs), and exists only in the recipient's browser.

This means Burn the Secret (or any attacker who compromises our servers) physically cannot decrypt your secrets. We only have the ciphertext, which is meaningless without the key.

The decryption process

When the recipient opens the link:

  1. The browser extracts the encryption key from the URL fragment
  2. The browser requests the encrypted ciphertext and IV from the server
  3. Decryption happens entirely in the browser using the fragment key
  4. The plaintext secret is displayed to the user
  5. The server deletes the encrypted data

Additional security layers

Passphrase protection. When you add a passphrase, it's SHA-256 hashed client-side before being sent to the server. The server stores only the hash and compares it when the recipient provides their passphrase. The actual passphrase is never transmitted or stored.

View limits. The server tracks view counts. Once the limit is reached, the encrypted data is immediately and permanently deleted, making the link completely unusable.

Time-based expiration. A background process continuously checks for expired secrets and deletes them. Expired data cannot be recovered under any circumstances.

HTTPS/TLS. All communications are over HTTPS with modern TLS, protecting against eavesdropping during transmission of the (already encrypted) ciphertext.

Security considerations

While one-time links provide strong security, there are still factors to consider.

One-time links protect against server breaches (data is encrypted), insider threats (zero-knowledge architecture), data persistence (automatic deletion), and network eavesdropping (TLS + encryption).

However, be aware of these limitations:

  • Link interception: If someone accesses the link before the intended recipient, they get the secret. Use passphrase protection for high-value credentials.
  • Browser history: The full URL (including fragment) may be saved in browser history. Use private browsing for sensitive links.
  • Post-viewing actions: After decryption, the recipient can copy or screenshot the content. One-time links protect transmission, not usage.

Ready to experience zero-knowledge security? Create a secure link on Burn the Secret.