JavaScript was originally designed as a browser language. It powers interactive websites and dynamic content. With Node.js, however, JavaScript began running on servers as well. “Deno and Node.js are so-called runtime environments. Put simply, they provide the functions a program needs to run outside the browser: access to files, network connections, or certain system information,” CISPA researcher Abdullah Alhamdan explains. And this is precisely where new security concerns arise. A program running on a server can cause significantly more damage than a script running in a browser.
The Security Promise of Deno
Deno addresses security on several fronts. It was written in Rust—a programming language designed to prevent typical memory errors. In addition, Deno introduces a strict permission system. Programs run in a kind of sandbox by default, meaning they are isolated and initially have no access to files, networks, or system functions. Every sensitive action must be explicitly authorized. The principle resembles smartphone permission systems: An app can only access the camera, microphone, or contacts if users allow it. “Deno is often portrayed as ‘secure by default,’” Alhamdan explains. “But its new security mechanisms don’t solve all of JavaScript’s fundamental problems.”
Smaller Attack Surface—But Not Immune to Attacks
Alhamdan’s study shows that Deno significantly reduces the attack surface compared to Node.js. Certain vulnerabilities—such as installation scripts in the Node package manager npm that are often manipulated to include malicious code—no longer exist in the same form. Memory-related errors are also far less likely because Deno is written in Rust. Still, risks from certain attack classes remain. “These include ReDoS attacks, where programs are blocked or severely slowed down through carefully crafted input. The widespread JavaScript issue of prototype chain pollution is also not fully prevented,” the researcher notes. In prototype chain pollution, attackers manipulate a shared template from which many program objects inherit properties. It’s like secretly swapping out a factory’s master blueprint—suddenly every machine starts producing defective parts.
Security As a Matter of Configuration
The biggest issue lies in Deno’s permission system itself. In theory, it significantly reduces risks. In practice, however, its effectiveness depends on how developers use it. For convenience, many grant overly broad permissions—such as “may read all files” or “may write anywhere.” These blanket permissions can allow more access than expected. According to Alhamdan’s study, a program with such permissions could, for example, read sensitive system information or modify files that are later executed outside Deno’s sandbox. The protective mechanisms formally remain in place—but practically lose their effect. The researchers refer to this phenomenon as “shadow permissions”—permissions that indirectly open up additional capabilities. They recommend granting rights more precisely and explicitly excluding certain files or addresses.
New Attack Paths Through URL Imports
A second key Deno feature concerns the integration of third-party code. Unlike Node.js, which relies on the centralized package manager npm, Deno allows third-party code to be imported directly via web URLs. The idea is to increase transparency and reduce dependence on a single platform. However, this decentralization creates new challenges. An analysis of the Deno ecosystem shows that code is loaded from numerous domains—sometimes via insecure protocols, sometimes from unstable or even freely registerable addresses. Moreover, not all platforms guarantee that once-published code remains unchanged. As a result, the security of the entire system depends on its weakest link. Supply-chain attacks therefore remain realistic in Deno as well. The researcher recommends mirror or backup solutions for external dependencies. Developers store a verified copy of external code instead of fetching it from the internet each time the program runs—preventing unnoticed changes or outages. This ensures the code does not silently change or disappear.
Technical Gaps in Enforcement
The study also identifies concrete technical weaknesses. Under certain conditions, fine-grained file permissions can be bypassed—for example, through symbolic links that point from an authorized directory to other areas of the system. “This issue can only be resolved through consistent technical enforcement of permissions,” says Alhamdan. At times, the import mechanism for external code itself was not fully integrated into the permission system. The researchers responsibly disclosed these problems to the manufacturer. Two security advisories were issued, and the import mechanism was subsequently revised.
What Does This Mean for “Secure by Default”?
Deno represents clear progress compared to Node.js. The attack surface is smaller, and many risks are reduced. But security does not emerge from good default settings alone. It depends on multiple factors—how precisely developers grant permissions, whether they vet third-party code, and whether they technically safeguard dependencies. “Security doesn’t mean preventing attacks entirely—it means making them as difficult as possible,” says Alhamdan. “Secure runtimes are an important layer of defense, but they don’t replace secure software development.” Deno is therefore a step in the right direction. But the lesson remains: “Secure by Default” does not automatically mean secure.
