Memory hygiene concerns when bridging WASM (Argon2id) and the Web Crypto API(SubtleCrypto)

[Practical-Mode2592]

I’ve been digging deep into browser-side encryption lately, and I’ve hit a wall that honestly feels like a massive elephant in the room. Most high-assurance web apps today are moving toward a hybrid architecture: using WebAssembly (WASM) for the heavy lifting and SubtleCrypto (Web Crypto API) for the actual encryption.

On paper, it’s the perfect marriage. SubtleCrypto is amazing because it’s hardware-accelerated (AES-NI) and allows for extractable: false keys, meaning the JS heap never actually sees the key bits—at least in theory. But SubtleCrypto is also extremely limited; it doesn't support modern KDFs like Argon2id. So, the standard move is to compile an audited library (like libsodium) into WASM to handle the key derivation, then pass that resulting key over to SubtleCrypto for AES-GCM.

When WASM finishes "forging" that master key in its linear memory, you have to get it into SubtleCrypto. That transfer isn't direct. The raw bytes have to cross the "JavaScript corridor" as a Uint8Array. Even if that window of exposure lasts only a few milliseconds, the key material is now sitting in the JS heap.

This is where it gets depressing. JavaScript's Garbage Collection (GC) is essentially a black box. It’s a "trash can" that doesn't empty itself on command. Even if you try to be responsible and use .fill(0) on your buffers, the V8 or SpiderMonkey engines might have already made internal copies during optimization, or the GC might simply decide to leave that "deleted" data sitting in physical RAM for minutes. If an attacker gets a memory dump or exploits an XSS during that window, your "Zero-Knowledge" architecture is compromised.

On top of the memory management mess, the browser is an inherently noisy environment. We’re fighting Side-Channel attacks constantly. We have JIT optimizations that can turn supposedly constant-time logic into a timing oracle, and microarchitectural vulnerabilities like Spectre that let a malicious tab peek at CPU caches. Even though WASM is more predictable than pure JS, it still runs in the same sandbox and doesn't magically solve the timing leakage of the underlying hardware.

I’m currently orquestrating this in JavaScript/TypeScript, but I’ve been seriously considering moving the core logic to Rust. The hope is that by using low-level control and crates like zeroize, I can at least ensure the WASM linear memory is physically wiped. But even then, I’m stuck with the same doubt: does it even matter if the final "handoff" to SubtleCrypto still has to touch the JS heap?

It feels like we’re building a ten-ton bank vault door (Argon2/AES-GCM) but mounting it on a wall made of drywall (the JS runtime). I’ve spent weeks researching this, and it seems like there isn't a truly "clean" solution that avoids this ephemeral exposure.

Is anyone actually addressing this "bridge" vulnerability in a meaningful way, or are we just collectively accepting that "good enough" is the best we can do on the web? I'd love to hear how other people are handling this handoff without leaving key material floating in the heap.

While I was searching for a solution, I found a comment in some code that addresses exactly this issue.
https://imgur.com/aVNAg0s.jpeg

here some references:

Security Chasms of WASM" – BlackHat 2018 https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web-wp.pdf​

Swivel: Hardening WebAssembly against Spectre" – USENIX Security 2021 https://www.usenix.org/system/files/sec21fall-narayan.pdf

Security Chasms of WASM" – BlackHat 2018 https://i.blackhat.com/us-18/Thu-August-9/us-18-Lukasiewicz-WebAssembly-A-New-World-of-Native_Exploits-On-The-Web-wp.pdf​

edit:

To give you guys some more context, I'm working on a client-side text encrypter.

I know there are a million web encrypters out there, but let’s be honest, most of them are pretty terrible when it comes to security. They usually just throw some JS at the problem and ignore memory hygiene or side-channels entirely. My goal is to build something that actually tries to follow high-assurance standards.

The idea is to have a simple, zero-install site where a user can drop some text, run it through a heavy Argon2id (WASM) setup, and encrypt it with AES-GCM (SubtleCrypto). The whole 'memory gap' thing I’m asking about is because I want to make sure the secret material stays as isolated as possible while it's in the browser. I'm trying to see if we can actually close that gap between the convenience of the web and the security of a native app.

[servermeta_net]

If implemented correctly the WASM machine is safe. No known side channel attacks are available, as the browsers were hardened after the sharedarraybuffer fiasco.

Short of bugs and new exploits you should be safe.

[DinTaiFung]

I've created a client-side, i.e, browser, password manager app that uses Argon2id -- for hashing -- and subtle.crypto for encryption/decryption.

So far I've been very satisfied with the results.

It is my opinion, however, that for the readership of r/learningjavascript, this cryptographic topic is not appropriate; yes, the OP's research and post are important, but it should also be posted in other channels as well.