Typically, chmod and iptables are not used to restrict applications. Applications are restricted by virtual machines, containers, sandboxes, AppArmor profiles, SELinux policies…

There's a fairly long history of giving applications their own uid to run under which puts chmod and chown in control of filesystem operations the app is allowed to perform. "Typically" maybe not, but it's hardly unusual.

iptables + namespaces gives you the rest.

+ you can make a network namespace and have separate iptables just for that namespace/app, you can for example give the namespace/app a VPN connection without affecting the rest of the system. And other apps can join the namespace and communicate as if they had their own isolated network.

NodeJS is also working on policies (1) which allows you to change permission to single modules or files.

1) https://nodejs.org/api/policy.html

chmod/chown has been the de facto (if not de jure) method securing LAMP stacks for as long as I have been alive. Not that I recommend taking the advice of a LAMP stack too seriously :)

If the de facto method refers to "chmod 777", I wouldn't call that securing ;-)

But indeed, if there is a separate user account for the application, then chmod can be used for some control to its access to files and directories.

A bit more like OpenBSD pledge() and unveil()