[bastawhiz]

> Surely there are many other exploitation factors such as running up the CPU...the primary use case would be ideal to help me understand.

You're probably running untrusted JavaScript in your browser right now. The difference between the V8 in Node and the V8 in your browser is that one is heavily locked down and the other can do essentially whatever the OS lets it.

If you have untrusted code to run, you can eliminate a whole class of security concerns by just not having a way for the code to do those things (i.e., making syscalls it shouldn't, forking, reading and writing to the disk or network, etc.). Sure, resource use can be an issue, but that's a problem that's more easily solvable further up the stack with VMs or containers. Just putting an instance of Node running untrusted code in a VM doesn't solve much, since the mechanism whereby you give it input and collect output can be manipulated by the untrusted code itself.

By making the runtime secure, you get the security of the browser (i.e., being able to visit a website without having to wipe your machine), but designed to run in a server environment.

[le-mark]

but that's a problem that's more easily solvable further up the stack with VMs or containers.

Everyone keeps saying this, let containers handle cpu/heap but I keep asking myself, is it really optimal?

[bastawhiz]

I mean, it certainly depends. But relying on your interpreter to manage CPU scheduling and memory use is almost certainly less ideal than letting your OS/hypervisor do that for you.