SecureString / SecureBytes - can be securely wiped out from memory

[WebWeWantBot]

---

title: SecureString / SecureBytes - can be securely wiped out from memory
date: 2025-03-21T14:46:59.064Z
submitter: castarco
number: 67dd7be38cc1b70076608e70
tags: [ ]
discussion: https://github.com/WebWeWant/webwewant.fyi/discussions/
status: [ discussing || in-progress || complete ]
related:

• title:
  url:
  type: [ article || explainer || draft || spec || note || discussion ]

---

The impact is low, but mainly because this is focused on protecting against sophisticated attacks.

What I'd like to have is a way to safely destroy the information contained within a string (GC is not enough).

In JS, strings are immutable, so as a userland developer I cannot manually overwrite them, and we don't have any guarantees about the GC clearing its bits once it frees the object.

Other form of typed arrays are not suited for the job because they don't compose well with many other JS APIs that are used to manage user inputs or any other form of sensitive information.

---

If posted, this will appear at https://webwewant.fyi/wants/67dd7be38cc1b70076608e70/

[catamorphism]

It's hard to imagine how to write a test for this feature, at least in the existing test262 framework. It seems like if you have a threat model where this capability is important, you would really want a formally verified implementation.

[justinmichaud]

Hi! What is the threat model here?

Other form of typed arrays are not suited for the job because they don't compose well with many other JS APIs that are used to manage user inputs or any other form of sensitive information.

This sounds like it would pessimize the entire engine.

Basically, I don't see how the following can be true at the same time:

• We can't trust the JS engine to not disclose the secret (implementation bugs, side channel attacks, etc...)
• We want to use the full power of the JS engine

The threat model used traditionally by some browser vendors is the web content process itself. If you have an arbitrary read primitive inside this process, you can read anything. You can probably also coerce the application to keep your secret alive, making the SecureString pointless. Any tighter boundary seems like it would be very very difficult to defend.

If you can share an example of the threat model you had in mind here, that would be super helpful! It would also be nice to know if there was a higher-level api that could serve your needs. For example, could operations involving the secret be done out-of-process?