If security principles are important they should be on a deny-default basis with allow-lists rather than the other way around.

If the deno runtime implements the fetch module itself, then post-resolution checking definitely should be done though. It's more of an bug though than a principled security lapse.

The thing is that this applies to all parts of the sandbox https://secfault-security.com/blog/deno.html

Ah, so by default it's default deny everything but once you need to open up categories, you can't just allow exact what you need in that category? You have to allow the entire category and then deny everything you don't want/need?

That's a bit of a silly model.

> you can't just allow exact what you need in that category? You have to allow the entire category and then deny everything you don't want/need?

No, you can allow access to specific domains, IP addresses, filesystem paths, environment variables, etc, while denying everything else by default. You can for instance allow access to only a specific IP (e.g. `deno run --allow-net='127.0.0.1' main.ts`), while implicitly blocking every other IP.

What the commenter is complaining about is the fact that Deno doesn't check which IP address a domain name actually resolves to using DNS resolution. So if you explicitly deny '1.1.1.1', and the script you're running fetches from a domain with an A record pointing to '1.1.1.1', Deno will allow it.

In practice, I usually use allow lists rather than deny lists, because I very rarely have an exhaustive list on hand of every IP address or domain I'm expecting a rogue script to attempt to access.

Yeah, that was my point, default deny vs default allow.

If you can default deny, then you're good. It's kind of a junior sysadmin mistake, otherwise, I would say.

There are usecases like SSRF where I want to allow any IP, except for my internal network. They promise they can do that, but they cant.

That isn't 90s security, that is just bad code. And bad code was written in the 90s and is still written today.