raw
current commit
261103.15 · doc: describe how the permission model grants the entrypoint
<(git log)

Permissions

Permissions can be used to control what system resources the Node.js process has access to or what actions the process can take with those resources.

The permission model implements a “seat belt” approach, which prevents trusted code from unintentionally changing files or using resources that access has not explicitly been granted to. It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code without the restrictions imposed by the permission model.

If you find a potential security vulnerability, please refer to our Security Policygithub.

Process-based permissions

Permission Model

Stability: 2 - Stable

The Node.js Permission Model is a mechanism for restricting access to specific resources during execution. The API exists behind a flag --permission which when enabled, will restrict access to all available permissions.

The available permissions are documented by the --permission flag.

The Permission Model has two operational modes:

When starting Node.js with --permission, the ability to access the file system through the fs module, access the network, access environment variables, spawn processes, use node:worker_threads, use native addons, use WASI, use FFI, and enable the runtime inspector will be restricted (the listener for SIGUSR1 won’t be created).

$ node --permission index.js

Error: Access to this API has been restricted
    at node:internal/main/run_main_module:23:47 {
  code: 'ERR_ACCESS_DENIED',
  permission: 'FileSystemRead',
  resource: '/home/user/index.js'
}

Allowing access to spawning a process and creating worker threads can be done using the --allow-child-process and --allow-worker respectively.

To grant access to environment variables, use --allow-env.

To allow network access, use --allow-net and for allowing native addons when using permission model, use the --allow-addons flag. For WASI, use the --allow-wasi flag. For FFI, use the --allow-ffi flag. The node:ffi module is only available in builds with FFI support.

To allow use of OpenSSL STORE loaders, for example to load a private key from a {URL} passed to crypto.createPrivateKey(), use the --allow-openssl-store flag. This flag grants broad authority to configured OpenSSL STORE loaders, which may access files, devices, tokens, or the network. Access performed by a loader is not constrained by the fs.read, fs.write, or net permission scopes.

Mounting a virtual file system with vfs.mount() throws ERR_INVALID_STATE unless the --allow-fs-vfs flag is passed. A mounted VFS serves paths that the file system permissions do not describe, so it is not gated by --allow-fs-read or --allow-fs-write.

Runtime API

When enabling the Permission Model through the --permission or --permission-audit flags, a new property permission is added to the process object. This property contains the following functions:

permission.has(scope[, reference])

API call to check permissions at runtime (permission.has())

process.permission.has('fs.write'); // true
process.permission.has('fs.write', '/home/rafaelgss/protected-folder'); // true

process.permission.has('fs.read'); // true
process.permission.has('fs.read', '/home/rafaelgss/protected-folder'); // false
permission.drop(scope[, reference])

API call to drop permissions at runtime. This operation is irreversible.

When called without a reference, the entire scope is dropped. When called with a reference, only the permission for that specific resource is revoked. Dropping a permission only affects future access checks. It does not close or revoke access to resources that are already open, such as file descriptors, network sockets, child processes, or worker threads. Applications are responsible for closing or terminating those resources when they are no longer needed.

You can only drop the exact resource that was explicitly granted. The reference passed to drop() must match the original grant. If a permission was granted using a wildcard (*), only the entire scope can be dropped (by calling drop() without a reference). If a directory was granted (e.g. --allow-fs-read=/my/folder), you cannot drop individual files inside it - you must drop the same directory that was originally granted.

const fs = require('node:fs');

// Read config at startup while we still have permission
const config = fs.readFileSync('/etc/myapp/config.json', 'utf8');

// Drop read access to /etc/myapp after initialization
process.permission.drop('fs.read', '/etc/myapp');

// This will now return false
process.permission.has('fs.read', '/etc/myapp/config.json'); // false

// Drop child process permission entirely
process.permission.drop('child');

Audit Mode

The --permission-audit flag enables audit mode for the Permission Model. In audit mode, permission checks are performed but access is not denied — no ERR_ACCESS_DENIED error is thrown. Instead, each permission violation is published through the node:diagnostics_channel module, allowing the application to observe and log which operations would be denied under enforce mode. Execution continues normally.

Audit mode is useful for discovering what permissions your application requires before deploying with --permission. It can also be combined with the --allow-fs-read, --allow-fs-write, --allow-fs-vfs, --allow-net, --allow-env, --allow-child-process, --allow-worker, --allow-addons, --allow-wasi, --allow-ffi, --allow-inspector, and --allow-openssl-store flags to audit a subset of permissions while granting others.

When a permission check fails in audit mode, a message is published to the diagnostics channel corresponding to the denied scope. The channel names are:

Each message is an object with the following properties:

const diagnostics_channel = require('node:diagnostics_channel');

diagnostics_channel.channel('node:permission-model:fs').subscribe((msg) => {
  console.log(`Permission denied: ${msg.permission} on ${msg.resource}`);
});

// Running with --permission-audit, this publishes a diagnostics channel
// message but does not throw
const fs = require('node:fs');
fs.readFileSync('/etc/passwd');

If both --permission and --permission-audit are specified, --permission takes precedence and the Permission Model runs in enforce mode.

File System Permissions

The Permission Model, by default, restricts access to the file system through the node:fs module. It does not guarantee that users will not be able to access the file system through other means, such as through the node:sqlite module.

To allow access to the file system, use the --allow-fs-read and --allow-fs-write flags:

$ node --permission --allow-fs-read=* --allow-fs-write=* index.js
Hello world!

By default the entrypoints of your application are included in the allowed file system read list. For example:

$ node --permission index.js
$ node -r /path/to/custom-require.js --permission index.js

The entrypoint is granted as passed on the command line, without the module loader’s resolution. If it is a directory, such as in node --permission ., read access is granted to everything inside that directory, recursively. If it omits the file extension, such as in node --permission index, the resolved index.js is not granted. Pass the full path of the file, or use --allow-fs-read, to grant exactly what the application needs.

The valid arguments for both flags are:

Example:

Wildcards are supported too:

After passing a wildcard character (*) all subsequent characters will be ignored. For example: /home/*.js will work similar to /home/*.

When the permission model is initialized, it will automatically add a wildcard (*) if the specified directory exists. For example, if /home/test/files exists, it will be treated as /home/test/files/*. However, if the directory does not exist, the wildcard will not be added, and access will be limited to /home/test/files. If you want to allow access to a folder that does not exist yet, make sure to explicitly include the wildcard: /my-path/folder-do-not-exist/*.

Some node:fs operations act on an already-open file descriptor rather than a path, so they cannot be tied to a --allow-fs-read or --allow-fs-write grant. When the permission model is enabled these operations are disabled and throw ERR_ACCESS_DENIED, regardless of how the descriptor was obtained. This applies both to the top-level node:fs functions and to the equivalent FileHandle methods, and currently includes fsync/fdatasync, fchmod, fchown, and futimes (and their synchronous variants).

Environment variable permissions

When the Permission Model is enforced, the process only has access to the environment variables that --allow-env grants access to.

Instead of checking each access, Node.js removes every other variable from the process environment at startup, before any JavaScript code runs and before Node.js starts any other thread. Removed variables are absent from everything that exposes the environment of the process: process.env, diagnostic reports, native code calling getenv(), worker threads, and the environment inherited by child processes.

$ node --permission --allow-env=PORT --allow-env=APP_* index.js

The valid arguments for the flag are:

Some variables are always kept:

NODE_ENV is not kept either. Node.js does not read it, but many applications and libraries do, and treat it being unset as a development environment. Grant access to it explicitly:

$ node --permission --allow-env=NODE_ENV index.js

Proxy URLs often contain credentials, so the HTTP_PROXY, HTTPS_PROXY, and NO_PROXY variables, and their lowercase forms, are not kept. Grant access to them explicitly when using --use-env-proxy. When --use-env-proxy is enabled and any of them were removed at startup, a warning naming them is emitted.

Native code that Node.js loads on behalf of the application, such as addons, OpenSSL providers and STORE loaders, and the libraries they load in turn, sees the same reduced environment. Only the variables that OpenSSL itself reads are kept, not those read by third-party modules it loads. For example, a PKCS#11 provider backed by SoftHSM needs SOFTHSM2_CONF to find its token, and fails to initialize without it. Grant access to such variables explicitly:

$ node --permission --allow-openssl-store --allow-env=SOFTHSM2_CONF index.js

Reading a variable that was removed at startup returns undefined, emits a warning the first time, and publishes a message to the node:permission-model:env diagnostics channel.

Variables set at runtime, for example with process.env.KEY = 'value' or process.loadEnvFile(), are not restricted, as they cannot reveal what was removed.

Dropping a variable with permission.drop() removes it from the environment. Dropping the whole env scope removes every variable except the ones Node.js reads itself. This makes it possible to read a secret during initialization, and then remove it:

const databaseUrl = process.env.DATABASE_URL;
process.permission.drop('env', 'DATABASE_URL');

Wildcards cannot be dropped: process.permission.drop('env', 'APP_*') and process.permission.drop('env', '*') throw ERR_INVALID_ARG_VALUE. To remove every variable, drop the whole env scope.

When a process that enforces the Permission Model spawns a child process, the child is started with --allow-env=*: the environment it inherits only contains variables that the parent had access to. The child can still read its own /proc/<pid>/environ on Linux, but not that of any other process, see below.

In audit mode, nothing is removed. Accesses to variables that --allow-env does not grant access to are published to the node:permission-model:env diagnostics channel instead.

On Linux, /proc/<pid>/environ exposes the environment a process was started with. When the Permission Model is enforced, reading the /proc/<pid>/environ file of any other process, including the parent process and its ancestors, is denied regardless of --allow-fs-read. Reading the process’s own file is only allowed with --allow-env=*. Symbolic links are resolved before the check, so paths that reach these files indirectly, such as /dev/fd/../environ, are denied as well.

In addition, the removed variables are overwritten in the initial environment block of the process, so that other processes do not find them in its /proc/<pid>/environ either. Variables removed later with permission.drop() are overwritten there as well.

These measures do not change the environment of other processes. A process granted --allow-child-process can read their environment through other programs.

Configuration file support

In addition to passing permission flags on the command line, they can also be declared in a Node.js configuration file when using the --config-file flag. Permission options must be placed inside the permission top-level object.

Example node.config.json:

{
  "permission": {
    "allow-fs-read": ["./foo"],
    "allow-fs-write": ["./bar"],
    "allow-child-process": true,
    "allow-worker": true,
    "allow-net": true,
    "allow-addons": false,
    "allow-ffi": false,
    "allow-openssl-store": false
  }
}

When the permission namespace is present in the configuration file, Node.js automatically enables the --permission flag. Run with:

$ node --config-file app.js

A configuration file, like the NODE_OPTIONS defined in an --env-file file, may be controlled by the project being run rather than by whoever starts Node.js. When the command line or the NODE_OPTIONS environment variable enable the Permission Model, the allow-env values these files define can only narrow the access that --allow-env grants, and never widen it:

$ node --permission --allow-env=APP_* --config-file=node.config.json app.js

With "allow-env": ["*"] in node.config.json, only the variables starting with APP_ are kept. With "allow-env": ["APP_DATABASE_URL", "OTHER"], only APP_DATABASE_URL is.

Using the Permission Model with npx

If you’re using npx to execute a Node.js script, you can enable the Permission Model by passing the --node-options flag. For example:

npx --node-options="--permission" package-name

This sets the NODE_OPTIONS environment variable for all Node.js processes spawned by npx, without affecting the npx process itself.

FileSystemRead Error with npx

The above command will likely throw a FileSystemRead invalid access error because Node.js requires file system read access to locate and execute the package. To avoid this:

  1. Using a Globally Installed Package Grant read access to the global node_modules directory by running:

    npx --node-options="--permission --allow-fs-read=$(npm prefix -g)" package-name

  2. Using the npx Cache If you are installing the package temporarily or relying on the npx cache, grant read access to the npm cache directory:

    npx --node-options="--permission --allow-fs-read=$(npm config get cache)" package-name

Any arguments you would normally pass to node (e.g., --allow-* flags) can also be passed through the --node-options flag. This flexibility makes it easy to configure permissions as needed when using npx.

Permission Model constraints

There are constraints you need to know before using this system:

process._debugProcess() and cross-process Inspector activation

The kInspector permission scope restricts the current process from opening its own V8 Inspector. However, process._debugProcess(pid) — which sends an OS-level signal (SIGUSR1 on POSIX, a remote thread on Windows) to an external process — is not gated by the kInspector scope or any other Permission Model scope.

A sandboxed process running under –permission with no additional grants can call process._debugProcess(pid) to force another Node.js process to open its V8 Inspector. The target process does not need to be running under –permission for this to work — any Node.js process running on the same host under the same OS user can be signaled.

This is consistent with the Node.js threat model: Node.js trusts the OS environment in which it runs. Cross-process signaling is an operating-system-level capability; restricting it is the responsibility of the operator (for example, using OS-level process isolation, separate OS users per process, or seccomp/AppArmor profiles on Linux).

Developers relying on –permission to sandbox untrusted code should be aware that:

Limitations and Known Issues