How secure is Bun compared to Deno?

[renet]

I've searched the GItHub issues and community, but didn't really find anything that told me about how Bun is thinking about and handling security. It's super fast - okay, but does that mean that security aspects are not that much in the focus of its developers (at least compared to Deno)? Is there any documentation about security concepts that I just didn't manage to find? Thanks a Bunch! 🥯

[Jarred-Sumner]

Rather than runtime permission checks (Deno's model) which could potentially have bugs that lead to permissions being ignored, Bun plans to have binary dead code elimination based on statically analyzing what features/native modules are used by the code.

Instead of checking if a feature is allowed at runtime, it is safer to just not have potentially unsafe or undesired code in the binary to begin with. Can't have bugs in code that doesn't exist

A different build of Bun will exist for each feature along with tooling for choosing the exact build of Bun with allowed features included. This will probably be limited to an edge runtime build of Bun (for Linux) focused on production usage in servers.

This is not implemented (or started) yet, but that's the plan.

Bun might explore runtime permission checks in the future, but it just doesn't seem as sound as not including the code to begin with.

Additionally, Bun will undergo regular security audits once a little more stable

[dzmitry-lahoda]

may be unix is way to go to run bun with restrictions at least on port/inode level via ebpf/jails?

would not ebpf modules and/or reverse proxy allow urls blocking?

[ronxjansen]

As someone who has first hand experienced a supply chain attack, I cannot stress enough the importance of granular permission levels - like Deno.

Not including a net or fs module is not a solution. Basically every project I have worked with needs these modules and you could whitelist the URLs and directories they are allowed to access.

Security is going to be more and more important in the years to come. For us it is already decisive to which stack we will use.

[lirantal]

+1

I've researched Bun's security posture and have put that together at https://www.bunsecurity.dev/
Did you by any chance see that before?

[ronxjansen]

@lirantal I did, although I feel "Bun secure-by-default" claim is at least exaggerated. One could also argue that this claim is misleading or false. Bun does not secure anything by default, other then not running pre/post install scripts. To my knowledge, the entire runtime is just as exposed as the Node.js runtime.

[lirantal]

I see what you mean and can relate. There are some aspects of Bun which demonstrate the "secure by default" paradigm (as you called out the pre/post install scripts is one of them), another is the "secure by design" paradigm around APIs.

Are there specific topics you'd expect the focus to be driven towards?

[lirantal]

Not entirely on this topic of permissions but I am building new Bun Security course and am interested to learn and hear what other topics and domains would be of interest to teach and educate on (specifically to Bun but also anything adjacent that makes sense).

[matthew-dean]

I think the first thing I would cover is that Deno has security by default and Bun, by default, is less secure.

[lirantal]

I haven't researched Deno so I can't genuinely comment about its security posture but Bun is taking some very proactive and smart secure by default and secure by design approach and very much to my liking.

[matthew-dean]

Oh? Did they add security since this thread? Like, do scripts now not have file / network etc access by default?

[lirantal]

There are other forms of security?

[Jobians]

Any updates?