Node's Security Problem
When you run a Node app, it has access to everything — your filesystem, the internet, the environment variables. And not just the app itself, but all of its dependencies, leaving your program and your users exposed to potentially untrusted, untested code.
This doesn’t make sense — why should your linter have complete control over your computer and network?
Node and npm vulnerabilities
Due to Node and its dependencies having unfettered access to everything and the hyper composability of npm modules, malicious npm modules have been reported to steal user data from forms, perform shell injection attacks, install malware onto your machine, and much more.
One particularly high profile supply chain attack was with the ua-parser-js,
which has around 7 million weekly downloads and is used among big tech companies
like Facebook, Amazon, Microsoft, Google, and more (Facebook’s fbjs library
which gets over 5 million weekly downloads depends on this library). In 2021,
this library was hijacked to install crypto mining and password stealing malware
onto the hosts’ machines. Without rigorous auditing of hundreds of dependencies,
millions of downstream projects were unaware of the access that ua-parser-js
had, compromising even more machines and end users’ sensitive data.
Deno: secure-by-default
Deno was built from the ground up with security as a core tenet.
By default, Deno programs don’t have access to the filesystem, the network, etc. — you need to explicitly opt into those via permission flags. Deno’s permission flags extend to its dependencies. You no longer need to conduct audits on your dependencies — simply run your program and see what access your app and its dependencies require.
Deno’s secure sandboxed environment means that you can run untrusted code and party dependencies with confidence.
Learn more about Deno’s security model: