JavaScript fanatics will downvote me, but I will say again. JavaScript is meant to be run in an untrusted environment (think browser), and running it in any form of trusted environment increases the risk drastically [1]

The language is too hard to do a meaningful static analysis. This particular attack is much harder (though not impossible) to execute in Java, Go, or Rust-based packages.

1 - https://ashishb.net/tech/javascript/

▲

tantalor 4 hours ago | parent | next [-]

Even in a browser, a compromised JS payload can put your user's data and privacy at risk.

▲

ashishb 4 hours ago | parent [-]

> Even in a browser, a compromised JS payload can put your user's data and privacy at risk.

True. In a backend, however, a compromised payload can put all of user's and your non-user data at risk.

	▲	Muromec 4 hours ago \| parent [-]
		> your non-user data at risk. That sounds like a GDPR fine waiting to be issued right there.

▲

mcintyre1994 4 hours ago | parent | prev [-]

In what way is it harder to write a library that exfiltrates credentials passed to it in those languages? I’d think it’d be a bit easier because you could use the standard library instead of custom encryption, but otherwise pretty much the same.

	▲	ashishb 4 hours ago \| parent [-]
		> In what way is it harder to write a library that exfiltrates credentials passed to it in those languages? It is not harder to write. It is more challenging to execute this attack stealthily. Due to the myriad behaviors of runtimes (browser vs. backend), frameworks (and their numerous versions), and over-dependency on external dependencies (e.g., leftpad), the risk in JS-based backends increases significantly.