Issue 1:
Deno is marketed as “A secure JavaScript and TypeScript runtime” and the philosophy behind the flags disabling syscalls seems to be “Deno default behavior prevents you from shooting yourself in the foot security wise”.

However, by default, Deno accepts to download libraries using http only. In other words, https is not enforced. There are two issues about this (#1063 and #1064).

The first one, has been dismissed with the argument that: [Deno] “should follow the browser conventions here - using a script tag to import http is allowed.” The other one is still open but has not had any activity in a couple months.

As long as a Deno process instantiates a module with an http import, a “man in the middle attack” is possible:

It means it is possible to tamper with the code of the module that is downloaded. Even if Deno has implemented integrity checks for modules, there are still some key attack vectors.

As I understand, there are still two cases when integrity checks are not enforced: The first download of a lib and the update of a lib. Moreover, even in the cases where integrity checks are enforced, someone could just prevent you from downloading this module, or do something even nastier: send garbage for an infinite time.

In this last case (according to a test I ran on 1.0.0-rc3), Deno will just be stuck forever downloading the module while seeing its RSS increase until something stops it (user or OS). In this case, any dependency (or sub dependency) could selectively prevent Deno apps from installing , reaching actually a Denial of Service case. (Service being, having Deno running the code).

Another attack: someone could eavesdrop on the module that is being downloaded. Eventually, Deno users will use authentication to download certain modules. Over http, the credentials will be transmitted in clear. It is noticeable that the popular (and very cool) package manager @yarnpkg has been having an issue with this (see CVE-2019-5448). It is very possible that someone will actually fill a CVE against Deno on that exact topic at one point.

All of that can be introduced by importing a library in https that would actually import another one using http only.

Overall, It’s pretty easy to fix. It should just “by default, disallow http for module resolution”. Maybe a flag could be used to re-enable it, following what I understand is the philosophy of the project regarding security flags. This would be a breaking change however.

I saw that following the prototype pollution events in the JavaScript world, it was decided to remove Object.prototype.__proto__ (see #4341). Actually, most browsers still support __proto__ (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/proto).

Here, the Deno team did the right thing, giving up browser compatibility to increase the default security level of the runtime. This is exactly the opposite of the decision taken regarding downloading modules using http only.

IMO, this defeats Deno being “Secure” if browser compatibility is more important than security. Deno is not a web browser. Also, web browsers have benefited from a lot of features regarding security hardening. For instance, security headers https://owasp.org/www-project-secure-headers/. Most of this would not make sense in Deno but they are here to update these behaviors.

(edit) Summary for ease of archieving:

current version of the project might be holding an instance of CWE-310 and/or CWE-311 out of similarity with CVE-2019-5448

current version of the project might be holding an instance of CWE-770

Issue 2:
For security reasons? (I believe for script tags in browsers would show warnings on loading an http resource while the page is loaded under https)