{"$schema":"https://doc-kit.nodejs.org/schemas/api-doc/1.0.0.json","id":"permissions","path":"/permissions","type":"module","module":"permissions","title":"Permissions","introducedIn":"v20.0.0","sourceLink":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"Permissions can be used to control what system resources the\nNode.js process has access to or what actions the process can take\nwith those resources.\n\n* [Process-based permissions](#process-based-permissions) control the Node.js\n  process's access to resources.\n  The resource can be entirely allowed or denied, or actions related to it can\n  be controlled. For example, file system reads can be allowed while denying\n  writes.\n  This feature does not protect against malicious code. According to the Node.js\n  [Security Policy](https://github.com/nodejs/node/blob/main/SECURITY.md), Node.js trusts any code it is asked to run.\n\nThe permission model implements a \"seat belt\" approach, which prevents trusted\ncode from unintentionally changing files or using resources that access has\nnot explicitly been granted to. It does not provide security guarantees in the\npresence of malicious code. Malicious code can bypass the permission model and\nexecute arbitrary code without the restrictions imposed by the permission\nmodel.\n\nIf you find a potential security vulnerability, please refer to our\n[Security Policy](https://github.com/nodejs/node/blob/main/SECURITY.md).","summary":"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.","examples":[],"children":[{"kind":"section","id":"process-based-permissions","name":"Process-based permissions","title":"Process-based permissions","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"","summary":"","examples":[],"children":[{"kind":"section","id":"permission-model","name":"Permission Model","title":"Permission Model","scope":"module","overloadOf":null,"stability":{"index":"2","description":"Stable"},"added":["v20.0.0"],"deprecated":[],"removed":[],"napiVersion":[],"changes":[{"versions":["v23.5.0","v22.13.0"],"prUrl":"https://github.com/nodejs/node/pull/56201","commit":null,"description":"This feature is no longer experimental."}],"description":"The Node.js Permission Model is a mechanism for restricting access to specific\nresources during execution.\nThe API exists behind a flag [`--permission`](cli.html#--permission) which when enabled,\nwill restrict access to all available permissions.\n\nThe available permissions are documented by the [`--permission`](cli.html#--permission)\nflag.\n\nThe Permission Model has two operational modes:\n\n* **Enforce mode** (default when using [`--permission`](cli.html#--permission)): Access is denied and\n  an `ERR_ACCESS_DENIED` error is thrown for any operation the process has not\n  been granted permission to perform.\n* **Audit mode** (when using [`--permission-audit`](cli.html#--permission-audit)): Permission checks are\n  performed and violations are published through the diagnostics channel, but\n  access is **not** denied. Execution continues normally. This mode is useful\n  for discovering what permissions your application requires before deploying\n  with enforce mode.\n\nWhen starting Node.js with `--permission`,\nthe ability to access the file system through the `fs` module, access the network,\nspawn processes, use `node:worker_threads`, use native addons, use WASI, use\nFFI, and enable the runtime inspector will be restricted (the listener for\nSIGUSR1 won't be created).\n\n```console\n$ node --permission index.js\n\nError: Access to this API has been restricted\n    at node:internal/main/run_main_module:23:47 {\n  code: 'ERR_ACCESS_DENIED',\n  permission: 'FileSystemRead',\n  resource: '/home/user/index.js'\n}\n```\n\nAllowing access to spawning a process and creating worker threads can be done\nusing the [`--allow-child-process`](cli.html#--allow-child-process) and [`--allow-worker`](cli.html#--allow-worker) respectively.\n\nTo allow network access, use [`--allow-net`](cli.html#--allow-net) and for allowing native addons\nwhen using permission model, use the [`--allow-addons`](cli.html#--allow-addons)\nflag. For WASI, use the [`--allow-wasi`](cli.html#--allow-wasi) flag. For FFI, use the\n[`--allow-ffi`](cli.html#--allow-ffi) flag. The [`node:ffi`](ffi.html) module also requires the\n`--experimental-ffi` flag and is only available in builds with FFI support.\n\nTo allow use of OpenSSL STORE loaders, for example to load a private key\nfrom a {URL} passed to [`crypto.createPrivateKey()`](crypto.html#cryptocreateprivatekeykey), use the\n[`--allow-openssl-store`](cli.html#--allow-openssl-store) flag.\nThis flag grants broad authority to configured OpenSSL STORE loaders, which may\naccess files, devices, tokens, or the network. Access performed by a loader is\nnot constrained by the `fs.read`, `fs.write`, or `net` permission scopes.","summary":"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.","examples":[{"language":"console","displayName":null,"code":"$ node --permission index.js\n\nError: Access to this API has been restricted\n    at node:internal/main/run_main_module:23:47 {\n  code: 'ERR_ACCESS_DENIED',\n  permission: 'FileSystemRead',\n  resource: '/home/user/index.js'\n}"}],"children":[{"kind":"section","id":"runtime-api","name":"Runtime API","title":"Runtime API","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"When enabling the Permission Model through the [`--permission`](cli.html#--permission)\nor [`--permission-audit`](cli.html#--permission-audit) flags, a new property `permission` is added to the\n`process` object. This property contains the following functions:","summary":"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:","examples":[],"children":[{"kind":"method","id":"permissionhasscope-reference","name":"has","title":"`permission.has(scope[, reference])`","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"signature":{"parameters":[{"name":"scope","type":null,"description":"","default":null,"optional":false,"rest":false,"properties":[]},{"name":"reference","type":null,"description":"","default":null,"optional":true,"rest":false,"properties":[]}],"returns":null},"description":"API call to check permissions at runtime ([`permission.has()`](process.html#processpermissionhasscope-reference))\n\n```js\nprocess.permission.has('fs.write'); // true\nprocess.permission.has('fs.write', '/home/rafaelgss/protected-folder'); // true\n\nprocess.permission.has('fs.read'); // true\nprocess.permission.has('fs.read', '/home/rafaelgss/protected-folder'); // false\n```","summary":"API call to check permissions at runtime (`permission.has()`)","examples":[{"language":"js","displayName":null,"code":"process.permission.has('fs.write'); // true\nprocess.permission.has('fs.write', '/home/rafaelgss/protected-folder'); // true\n\nprocess.permission.has('fs.read'); // true\nprocess.permission.has('fs.read', '/home/rafaelgss/protected-folder'); // false"}],"children":[]},{"kind":"method","id":"permissiondropscope-reference","name":"drop","title":"`permission.drop(scope[, reference])`","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"signature":{"parameters":[{"name":"scope","type":null,"description":"","default":null,"optional":false,"rest":false,"properties":[]},{"name":"reference","type":null,"description":"","default":null,"optional":true,"rest":false,"properties":[]}],"returns":null},"description":"API call to drop permissions at runtime. This operation is **irreversible**.\n\nWhen called without a reference, the entire scope is dropped. When called\nwith a reference, only the permission for that specific resource is revoked.\nDropping a permission only affects future access checks. It does not close or\nrevoke access to resources that are already open, such as file descriptors,\nnetwork sockets, child processes, or worker threads. Applications are\nresponsible for closing or terminating those resources when they are no longer\nneeded.\n\nYou can only drop the exact resource that was explicitly granted. The\nreference passed to `drop()` must match the original grant. If a permission\nwas granted using a wildcard (`*`), only the entire scope can be dropped\n(by calling `drop()` without a reference). If a directory was granted\n(e.g. `--allow-fs-read=/my/folder`), you cannot drop individual files\ninside it - you must drop the same directory that was originally granted.\n\n```js\nconst fs = require('node:fs');\n\n// Read config at startup while we still have permission\nconst config = fs.readFileSync('/etc/myapp/config.json', 'utf8');\n\n// Drop read access to /etc/myapp after initialization\nprocess.permission.drop('fs.read', '/etc/myapp');\n\n// This will now return false\nprocess.permission.has('fs.read', '/etc/myapp/config.json'); // false\n\n// Drop child process permission entirely\nprocess.permission.drop('child');\n```","summary":"API call to drop permissions at runtime. This operation is **irreversible**.","examples":[{"language":"js","displayName":null,"code":"const fs = require('node:fs');\n\n// Read config at startup while we still have permission\nconst config = fs.readFileSync('/etc/myapp/config.json', 'utf8');\n\n// Drop read access to /etc/myapp after initialization\nprocess.permission.drop('fs.read', '/etc/myapp');\n\n// This will now return false\nprocess.permission.has('fs.read', '/etc/myapp/config.json'); // false\n\n// Drop child process permission entirely\nprocess.permission.drop('child');"}],"children":[]}]},{"kind":"section","id":"audit-mode","name":"Audit Mode","title":"Audit Mode","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"The [`--permission-audit`](cli.html#--permission-audit) flag enables audit mode for the Permission Model.\nIn audit mode, permission checks are performed but access is **not** denied —\nno `ERR_ACCESS_DENIED` error is thrown. Instead, each permission violation is\npublished through the `node:diagnostics_channel` module, allowing the\napplication to observe and log which operations would be denied under enforce\nmode. Execution continues normally.\n\nAudit mode is useful for discovering what permissions your application\nrequires before deploying with [`--permission`](cli.html#--permission). It can also be combined\nwith the [`--allow-fs-read`](cli.html#--allow-fs-read), [`--allow-fs-write`](cli.html#--allow-fs-write), [`--allow-net`](cli.html#--allow-net),\n[`--allow-child-process`](cli.html#--allow-child-process), [`--allow-worker`](cli.html#--allow-worker), [`--allow-addons`](cli.html#--allow-addons),\n[`--allow-wasi`](cli.html#--allow-wasi), and [`--allow-ffi`](cli.html#--allow-ffi) flags to audit a subset of\npermissions while granting others.\n\nWhen a permission check fails in audit mode, a message is published to the\ndiagnostics channel corresponding to the denied scope. The channel names are:\n\n* `node:permission-model:fs` — File System (read and write)\n* `node:permission-model:net` — Network\n* `node:permission-model:child` — Child Process\n* `node:permission-model:worker` — Worker Threads\n* `node:permission-model:inspector` — Inspector\n* `node:permission-model:wasi` — WASI\n* `node:permission-model:addon` — Native Addons\n* `node:permission-model:ffi` — FFI\n\nEach message is an object with the following properties:\n\n* `permission` {string} The name of the denied permission scope.\n* `resource` {string} The resource that access was denied to (e.g. a file path\n  or host).\n\n```js\nconst diagnostics_channel = require('node:diagnostics_channel');\n\ndiagnostics_channel.channel('node:permission-model:fs').subscribe((msg) => {\n  console.log(`Permission denied: ${msg.permission} on ${msg.resource}`);\n});\n\n// Running with --permission-audit, this publishes a diagnostics channel\n// message but does not throw\nconst fs = require('node:fs');\nfs.readFileSync('/etc/passwd');\n```\n\nIf both [`--permission`](cli.html#--permission) and [`--permission-audit`](cli.html#--permission-audit) are specified,\n`--permission` takes precedence and the Permission Model runs in enforce mode.","summary":"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.","examples":[{"language":"js","displayName":null,"code":"const diagnostics_channel = require('node:diagnostics_channel');\n\ndiagnostics_channel.channel('node:permission-model:fs').subscribe((msg) => {\n  console.log(`Permission denied: ${msg.permission} on ${msg.resource}`);\n});\n\n// Running with --permission-audit, this publishes a diagnostics channel\n// message but does not throw\nconst fs = require('node:fs');\nfs.readFileSync('/etc/passwd');"}],"children":[]},{"kind":"section","id":"file-system-permissions","name":"File System Permissions","title":"File System Permissions","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"The Permission Model, by default, restricts access to the file system through the `node:fs` module.\nIt does not guarantee that users will not be able to access the file system through other means,\nsuch as through the `node:sqlite` module.\n\nTo allow access to the file system, use the [`--allow-fs-read`](cli.html#--allow-fs-read) and\n[`--allow-fs-write`](cli.html#--allow-fs-write) flags:\n\n```console\n$ node --permission --allow-fs-read=* --allow-fs-write=* index.js\nHello world!\n```\n\nBy default the entrypoints of your application are included\nin the allowed file system read list. For example:\n\n```console\n$ node --permission index.js\n```\n\n* `index.js` will be included in the allowed file system read list\n\n```console\n$ node -r /path/to/custom-require.js --permission index.js\n```\n\n* `/path/to/custom-require.js` will be included in the allowed file system read\n  list.\n* `index.js` will be included in the allowed file system read list.\n\nThe valid arguments for both flags are:\n\n* `*` - To allow all `FileSystemRead` or `FileSystemWrite` operations,\n  respectively.\n* Relative paths to the current working directory.\n* Absolute paths.\n\nExample:\n\n* `--allow-fs-read=*` - It will allow all `FileSystemRead` operations.\n* `--allow-fs-write=*` - It will allow all `FileSystemWrite` operations.\n* `--allow-fs-write=/tmp/` - It will allow `FileSystemWrite` access to the `/tmp/`\n  folder.\n* `--allow-fs-read=/tmp/ --allow-fs-read=/home/.gitignore` - It allows `FileSystemRead` access\n  to the `/tmp/` folder **and** the `/home/.gitignore` path.\n\nWildcards are supported too:\n\n* `--allow-fs-read=/home/test*` will allow read access to everything\n  that matches the wildcard. e.g: `/home/test/file1` or `/home/test2`\n\nAfter passing a wildcard character (`*`) all subsequent characters will\nbe ignored. For example: `/home/*.js` will work similar to `/home/*`.\n\nWhen the permission model is initialized, it will automatically add a wildcard\n(\\*) if the specified directory exists. For example, if `/home/test/files`\nexists, it will be treated as `/home/test/files/*`. However, if the directory\ndoes not exist, the wildcard will not be added, and access will be limited to\n`/home/test/files`. If you want to allow access to a folder that does not exist\nyet, make sure to explicitly include the wildcard:\n`/my-path/folder-do-not-exist/*`.","summary":"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.","examples":[{"language":"console","displayName":null,"code":"$ node --permission --allow-fs-read=* --allow-fs-write=* index.js\nHello world!"},{"language":"console","displayName":null,"code":"$ node --permission index.js"},{"language":"console","displayName":null,"code":"$ node -r /path/to/custom-require.js --permission index.js"}],"children":[]},{"kind":"section","id":"configuration-file-support","name":"Configuration file support","title":"Configuration file support","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"In addition to passing permission flags on the command line, they can also be\ndeclared in a Node.js configuration file when using the experimental\n\\[`--experimental-config-file`]\\[] flag. Permission options must be placed inside\nthe `permission` top-level object.\n\nExample `node.config.json`:\n\n```json\n{\n  \"permission\": {\n    \"allow-fs-read\": [\"./foo\"],\n    \"allow-fs-write\": [\"./bar\"],\n    \"allow-child-process\": true,\n    \"allow-worker\": true,\n    \"allow-net\": true,\n    \"allow-addons\": false,\n    \"allow-ffi\": false,\n    \"allow-openssl-store\": false\n  }\n}\n```\n\nWhen the `permission` namespace is present in the configuration file, Node.js\nautomatically enables the `--permission` flag. Run with:\n\n```console\n$ node --experimental-default-config-file app.js\n```","summary":"In addition to passing permission flags on the command line, they can also be declared in a Node.js configuration file when using the experimental [`--experimental-config-file`][] flag. Permission options must be placed inside the `permission` top-level object.","examples":[{"language":"json","displayName":null,"code":"{\n  \"permission\": {\n    \"allow-fs-read\": [\"./foo\"],\n    \"allow-fs-write\": [\"./bar\"],\n    \"allow-child-process\": true,\n    \"allow-worker\": true,\n    \"allow-net\": true,\n    \"allow-addons\": false,\n    \"allow-ffi\": false,\n    \"allow-openssl-store\": false\n  }\n}"},{"language":"console","displayName":null,"code":"$ node --experimental-default-config-file app.js"}],"children":[]},{"kind":"section","id":"using-the-permission-model-with-npx","name":"Using the Permission Model with npx","title":"Using the Permission Model with `npx`","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"If you're using [`npx`](https://docs.npmjs.com/cli/commands/npx) to execute a Node.js script, you can enable the\nPermission Model by passing the `--node-options` flag. For example:\n\n```bash\nnpx --node-options=\"--permission\" package-name\n```\n\nThis sets the `NODE_OPTIONS` environment variable for all Node.js processes\nspawned by [`npx`](https://docs.npmjs.com/cli/commands/npx), without affecting the `npx` process itself.\n\n**FileSystemRead Error with `npx`**\n\nThe above command will likely throw a `FileSystemRead` invalid access error\nbecause Node.js requires file system read access to locate and execute the\npackage. To avoid this:\n\n1. **Using a Globally Installed Package**\n   Grant read access to the global `node_modules` directory by running:\n\n   ```bash\n   npx --node-options=\"--permission --allow-fs-read=$(npm prefix -g)\" package-name\n   ```\n\n2. **Using the `npx` Cache**\n   If you are installing the package temporarily or relying on the `npx` cache,\n   grant read access to the npm cache directory:\n\n   ```bash\n   npx --node-options=\"--permission --allow-fs-read=$(npm config get cache)\" package-name\n   ```\n\nAny arguments you would normally pass to `node` (e.g., `--allow-*` flags) can\nalso be passed through the `--node-options` flag. This flexibility makes it\neasy to configure permissions as needed when using `npx`.","summary":"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:","examples":[{"language":"bash","displayName":null,"code":"npx --node-options=\"--permission\" package-name"},{"language":"bash","displayName":null,"code":"npx --node-options=\"--permission --allow-fs-read=$(npm prefix -g)\" package-name"},{"language":"bash","displayName":null,"code":"npx --node-options=\"--permission --allow-fs-read=$(npm config get cache)\" package-name"}],"children":[]},{"kind":"section","id":"permission-model-constraints","name":"Permission Model constraints","title":"Permission Model constraints","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"There are constraints you need to know before using this system:\n\n* The model does not inherit to a worker thread.\n* When using the Permission Model the following features will be restricted:\n  * Native modules\n  * Network\n  * Child process\n  * Worker Threads\n  * Inspector protocol\n  * File system access\n  * WASI\n  * FFI\n  * OpenSSL STORE loaders\n* The Permission Model is initialized after the Node.js environment is set up.\n  However, certain flags such as `--env-file` or `--openssl-config` are designed\n  to read files before environment initialization. As a result, such flags are\n  not subject to the rules of the Permission Model. The same applies for V8\n  flags that can be set via runtime through `v8.setFlagsFromString`.\n* OpenSSL engines cannot be requested at runtime when the Permission\n  Model is enabled, affecting the built-in crypto, https, and tls modules.\n* Run-Time Loadable Extensions cannot be loaded when the Permission Model is\n  enabled, affecting the sqlite module.\n* Using existing file descriptors via the `node:fs` module bypasses the\n  Permission Model.","summary":"There are constraints you need to know before using this system:","examples":[],"children":[]},{"kind":"section","id":"process_debugprocess-and-cross-process-inspector-activation","name":"process._debugProcess() and cross-process Inspector activation","title":"process._debugProcess() and cross-process Inspector activation","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"The `kInspector` permission scope restricts the current process from opening its own V8 Inspector. However,\nprocess.\\_debugProcess(pid) — which sends an OS-level signal (SIGUSR1 on POSIX, a remote thread on Windows)\nto an external process — is not gated by the `kInspector` scope or any other Permission Model scope.\n\nA sandboxed process running under --permission with no additional grants can call process.\\_debugProcess(pid)\nto force another Node.js process to open its V8 Inspector. The target process does not need to be running\nunder --permission for this to work — any Node.js process running on the same host under the same OS user\ncan be signaled.\n\nThis is consistent with the Node.js threat model: Node.js trusts the OS environment in which it runs.\nCross-process signaling is an operating-system-level capability; restricting it is the responsibility of\nthe operator (for example, using OS-level process isolation, separate OS users per process, or\nseccomp/AppArmor profiles on Linux).\n\nDevelopers relying on --permission to sandbox untrusted code should be aware that:\n\n* process.\\_debugProcess() is callable from any sandboxed process with no grants.\n* If a target Node.js process is running on the same host under the same OS user, it can be forced to\n  open its Inspector via this API.\n* To prevent this, run sandboxed and target processes under different OS users, or use OS-level isolation\n  mechanisms outside of Node.js.","summary":"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.","examples":[],"children":[]},{"kind":"section","id":"limitations-and-known-issues","name":"Limitations and Known Issues","title":"Limitations and Known Issues","scope":"module","overloadOf":null,"stability":null,"added":[],"deprecated":[],"removed":[],"napiVersion":[],"changes":[],"description":"* Symbolic links will be followed even to locations outside of the set of paths\n  that access has been granted to. Relative symbolic links may allow access to\n  arbitrary files and directories. When starting applications with the\n  permission model enabled, you must ensure that no paths to which access has\n  been granted contain relative symbolic links.","summary":"","examples":[],"children":[]}]}]}]}