How We Built Zero-Knowledge Secret Sharing on Cloudflare Workers (Not Secrets Store)

Search queries like cloudflare secret store or cloudflare secrets store often land on two different problems. Cloudflare's Secrets Store is a platform product: it stores configuration secrets (Worker API tokens, third-party credentials, signing keys) that your code reads through bindings at runtime. It protects your infrastructure's secrets from leaking in source control or wrangler.toml — not from your Worker operator reading them (Cloudflare holds them for delivery to your Worker).

VanishingVault/SecretDropBox solves a different job: users paste a password or API key once, the browser encrypts it client-side, and a recipient opens a burn-after-read link. The Worker is a blind courier — it stores ciphertext in KV and deletes on first read. The decryption key never leaves the URL fragment. That is zero-knowledge secret sharing, not secrets management for your deploy pipeline.

The fragment-key + Web Crypto model still matches how open-source Cloudflare ZK drops are built. The production gaps we would close next (and that peers already document):

• Durable Objects on the burn path — serialize get→delete per secret ID so two parallel readers cannot both receive ciphertext. Cloudflare’s DO input gates exist for exactly this class of race.
• Explicit Reveal click — landing page loads metadata only; ciphertext fetch + delete runs after a human click so Slack/Teams unfurls do not burn the link.
• Security headers — CSP that blocks unexpected scripts, Referrer-Policy: no-referrer, X-Frame-Options: DENY so IDs and accidental fragment leakage via referrers are harder.
• Optional R2 for larger blobs — keep small password handoffs in KV/DO storage; put bigger encrypted files in R2 with the same fragment key.

None of that changes the product job: a blind courier for one-time secrets. See also why zero-knowledge architecture should be the default.

The design constraint was simple: the provider must never be able to read a secret, even with full infrastructure access. That rules out server-side encryption with provider-held keys. Encryption happens exclusively in the browser; the Worker is a courier for opaque blobs.

Architecture Overview

Two tiers, not three. The Next.js frontend owns all crypto via the Web Crypto API. Sensitive data becomes ciphertext before it leaves the device. The Cloudflare Worker receives encrypted blobs and stores them in KV without any ability to decrypt. If the entire backend were compromised, attackers would find ciphertext and IVs — not keys.

What Never Touches the Server

• Plaintext secrets
• AES encryption keys (URL fragment only)
• User accounts or identity for anonymous shares

What does touch the server: ciphertext, IV, a random ID, and a TTL. That is the entire trust boundary.

Backend Implementation with Cloudflare Workers

Core store and retrieve (burn-after-read) handlers:

// Store endpoint - saves an encrypted secret
async function handleStore(request) {
  const { encryptedData, expiresAt } = await request.json();
  
  // Generate a random ID for the secret
  const id = crypto.randomUUID();
  
  // Store the encrypted data in KV with TTL
  await SECRETS_STORE.put(
    id,
    JSON.stringify({ encryptedData }),
    { expirationTtl: 604800 } // 7 days in seconds
  );
  
  return new Response(
    JSON.stringify({ id }),
    { headers: { 'Content-Type': 'application/json' } }
  );
}

// Retrieve endpoint - gets and deletes a secret (one-time access)
async function handleRetrieve(request, id) {
  // Get the secret from KV
  const secretData = await SECRETS_STORE.get(id);
  
  if (!secretData) {
    return new Response(
      JSON.stringify({ error: 'Secret not found or already viewed' }),
      { status: 404, headers: { 'Content-Type': 'application/json' } }
    );
  }
  
  // Delete the secret immediately (one-time access)
  await SECRETS_STORE.delete(id);
  
  return new Response(
    secretData,
    { headers: { 'Content-Type': 'application/json' } }
  );
}

Frontend Encryption with Web Crypto API

On the frontend, we use the Web Crypto API (secure contexts only: HTTPS or localhost) to handle encryption and decryption — no third-party crypto libraries:

// Generate a random encryption key
async function generateEncryptionKey() {
  return window.crypto.subtle.generateKey(
    { name: "AES-GCM", length: 256 },
    true,
    ["encrypt", "decrypt"]
  );
}

// Encrypt data with the generated key
async function encryptData(key, data) {
  // Create a random initialization vector
  const iv = window.crypto.getRandomValues(new Uint8Array(12));
  
  // Encode the data as UTF-8
  const encodedData = new TextEncoder().encode(data);
  
  // Encrypt the data
  const encryptedBuffer = await window.crypto.subtle.encrypt(
    { name: "AES-GCM", iv },
    key,
    encodedData
  );
  
  // Convert the encrypted data and IV to base64
  const encryptedData = bufferToBase64(encryptedBuffer);
  const ivBase64 = bufferToBase64(iv);
  
  return { encryptedData, iv: ivBase64 };
}

// Decrypt data with the provided key
async function decryptData(key, encryptedData, iv) {
  // Convert base64 back to ArrayBuffer
  const encryptedBuffer = base64ToBuffer(encryptedData);
  const ivBuffer = base64ToBuffer(iv);
  
  // Decrypt the data
  const decryptedBuffer = await window.crypto.subtle.decrypt(
    { name: "AES-GCM", iv: ivBuffer },
    key,
    encryptedBuffer
  );
  
  // Decode the decrypted data as UTF-8
  return new TextDecoder().decode(decryptedBuffer);
}

Secret URL Generation

When a user creates a secret, we:

1. Generate a random encryption key
2. Encrypt the secret with this key
3. Send the encrypted data to the server
4. Receive a unique ID from the server
5. Create a URL with the ID and the encryption key as a fragment

The encryption key is never sent to the server. Instead, it's added as a URL fragment (the part after the # symbol). Browsers do not include fragments in HTTP requests, so Workers and KV never receive the key — even in access logs.

// Create a secret URL
async function createSecretUrl(secret) {
  // Generate a random encryption key
  const key = await generateEncryptionKey();
  
  // Export the key to raw format
  const rawKey = await window.crypto.subtle.exportKey("raw", key);
  
  // Convert the key to base64
  const keyBase64 = bufferToBase64(rawKey);
  
  // Encrypt the secret
  const { encryptedData, iv } = await encryptData(key, secret);
  
  // Send the encrypted data to the server
  const response = await fetch('/api/store', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ encryptedData, iv })
  });
  
  const { id } = await response.json();
  
  // Create the secret URL with the key as a fragment
  return `${window.location.origin}/s/${id}#k=${keyBase64}`;
}

Deploying our solution to production was straightforward thanks to Cloudflare's developer-friendly tools:

1. Setting Up the KV Namespace

# Create a KV namespace for secrets
wrangler kv:namespace create "SECRETS_STORE"

# Add the namespace to wrangler.toml
# kv_namespaces = [
#   { binding = "SECRETS_STORE", id = "your-namespace-id" }
# ]

2. Configuring CORS for Multiple Domains

Since we operate on two domains (vanishingvault.com and secretdropbox.com), we needed to configure CORS properly:

// CORS headers function
function corsHeaders(request) {
  // Get the origin from the request
  const origin = request.headers.get('Origin');
  const allowedOrigins = [
    'https://secretdropbox.com',
    'https://vanishingvault.com',
    'http://localhost:3000' // For development
  ];
  
  // Check if the origin is allowed
  const allowedOrigin = allowedOrigins.includes(origin) 
    ? origin 
    : allowedOrigins[0];
  
  return {
    'Access-Control-Allow-Origin': allowedOrigin,
    'Access-Control-Allow-Methods': 'GET, POST, DELETE, OPTIONS',
    'Access-Control-Allow-Headers': 'Content-Type',
    'Access-Control-Max-Age': '86400',
  };
}

3. Deploying the Worker

# Deploy the worker
wrangler deploy

# Configure custom domain routes
# In your Cloudflare dashboard:
# - Add a route pattern: secretdropbox.com/api/*
# - Add a route pattern: vanishingvault.com/api/*

Our zero-knowledge secret sharing tool is designed to address a variety of secure sharing needs:

• Share sensitive personal information with family members
• Securely transmit passwords to friends
• Send private account details to trusted contacts
• Share temporary access codes without leaving a trace

VanishingVault gives privacy-conscious individuals a secure way to share sensitive information. By leveraging Cloudflare's edge infrastructure and client-side encryption, secrets stay under user control while delivery stays global and simple.

Compare the wider landscape in best one-time secret sharing tools.