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

[samuba]

@kevlened Deno offers white/black listing for urls, file paths etc.
https://deno.land/[email protected]/basics/permissions

[kevlened]

@samuba Ah, I misunderstood. I assumed you meant your code could access /temp/myApp, while 3rd parties could not.

Deno's permissions are more granular than the current scope of this proposal.

[matthew-dean]

This... answer doesn't really make sense. Deno, for example, allows you to evaluate any arbitrary untrusted JavaScript code from a third-party without, say, allowing file access. By restricting file access or file access only to supplied directories, you can provide things like a scripting language from user input that runs in server process, but which has no access to system resources. Dead code elimination and static analysis don't address this. Without a secure-by-default model (or at least an adjustable security model?), it makes Bun unusable for scenarios in which the JS / TS code cannot and should not be trusted.

[matthew-dean]

Unless Bun provides some kind of secure VM somehow that doesn't allow access to system resources or the process object etc etc?

[dzmitry-lahoda]

may be unix is way to go to run bun with resfrictions at least on port/inode level?

sure that will not allow glob urls.

but would not ebpf modules allow urls?

[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?