Skip to main content
Deno 2 is finally here πŸŽ‰οΈ
Learn more

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.

example of running the same attack in Deno and failing

Deno’s secure sandboxed environment means that you can run untrusted code and party dependencies with confidence.

Learn more about Deno’s security model: