Node.js contains experimental support for creating policies on loading code.
\nPolicies are a security feature intended to allow guarantees\nabout what code Node.js is able to load. The use of policies assumes\nsafe practices for the policy files such as ensuring that policy\nfiles cannot be overwritten by the Node.js application by using\nfile permissions.
\nA best practice would be to ensure that the policy manifest is read-only for\nthe running Node.js application and that the file cannot be changed\nby the running Node.js application in any way. A typical setup would be to\ncreate the policy file as a different user id than the one running Node.js\nand granting read permissions to the user id running Node.js.
", "miscs": [ { "textRaw": "Enabling", "name": "Enabling", "type": "misc", "desc": "The --experimental-policy flag can be used to enable features for policies\nwhen loading modules.
Once this has been set, all modules must conform to a policy manifest file\npassed to the flag:
\nnode --experimental-policy=policy.json app.js\nThe policy manifest will be used to enforce constraints on code loaded by\nNode.js.
\nTo mitigate tampering with policy files on disk, an integrity for\nthe policy file itself may be provided via --policy-integrity.\nThis allows running node and asserting the policy file contents\neven if the file is changed on disk.
node --experimental-policy=policy.json --policy-integrity=\"sha384-SggXRQHwCG8g+DktYYzxkXRIkTiEYWBHqev0xnpCxYlqMBufKZHAHQM3/boDaI/0\" app.js\nWhen a policy check fails, Node.js by default will throw an error.\nIt is possible to change the error behavior to one of a few possibilities\nby defining an \"onerror\" field in a policy manifest. The following values are\navailable to change the behavior:
\n\"exit\": will exit the process immediately.\nNo cleanup code will be allowed to run.\"log\": will log the error at the site of the failure.\"throw\": will throw a JS error at the site of the failure. This is the\ndefault.{\n \"onerror\": \"log\",\n \"resources\": {\n \"./app/checked.js\": {\n \"integrity\": \"sha384-SggXRQHwCG8g+DktYYzxkXRIkTiEYWBHqev0xnpCxYlqMBufKZHAHQM3/boDaI/0\"\n }\n }\n}\nPolicy files must use integrity checks with Subresource Integrity strings\ncompatible with the browser\nintegrity attribute\nassociated with absolute URLs.
\nWhen using require() all resources involved in loading are checked for\nintegrity if a policy manifest has been specified. If a resource does not match\nthe integrity listed in the manifest, an error will be thrown.
An example policy file that would allow loading a file checked.js:
{\n \"resources\": {\n \"./app/checked.js\": {\n \"integrity\": \"sha384-SggXRQHwCG8g+DktYYzxkXRIkTiEYWBHqev0xnpCxYlqMBufKZHAHQM3/boDaI/0\"\n }\n }\n}\nEach resource listed in the policy manifest can be of one the following\nformats to determine its location:
\n./resource.js, ../resource.js, or /resource.js.file:///resource.js.When loading resources the entire URL must match including search parameters\nand hash fragment. ./a.js?b will not be used when attempting to load\n./a.js and vice versa.
To generate integrity strings, a script such as\nprintf \"sha384-$(cat checked.js | openssl dgst -sha384 -binary | base64)\"\ncan be used.
Integrity can be specified as the boolean value true to accept any\nbody for the resource which can be useful for local development. It is not\nrecommended in production since it would allow unexpected alteration of\nresources to be considered valid.
An application may need to ship patched versions of modules or to prevent\nmodules from allowing all modules access to all other modules. Redirection\ncan be used by intercepting attempts to load the modules wishing to be\nreplaced.
\n{\n \"resources\": {\n \"./app/checked.js\": {\n \"dependencies\": {\n \"fs\": true,\n \"os\": \"./app/node_modules/alt-os\",\n \"http\": { \"import\": true }\n }\n }\n }\n}\nThe dependencies are keyed by the requested specifier string and have values\nof either true, null, a string pointing to a module to be resolved,\nor a conditions object.
The specifier string does not perform any searching and must match exactly\nwhat is provided to the require() or import. Therefore, multiple specifiers\nmay be needed in the policy if it uses multiple different strings to point\nto the same module (such as excluding the extension).
If the value of the redirection is true the default searching algorithms are\nused to find the module.
If the value of the redirection is a string, it is resolved relative to\nthe manifest and then immediately used without searching.
\nAny specifier string for which resolution is attempted and that is not listed in\nthe dependencies results in an error according to the policy.
\nRedirection does not prevent access to APIs through means such as direct access\nto require.cache or through module.constructor which allow access to\nloading modules. Policy redirection only affects specifiers to require() and\nimport. Other means, such as to prevent undesired access to APIs through\nvariables, are necessary to lock down that path of loading modules.
A boolean value of true for the dependencies map can be specified to allow a\nmodule to load any specifier without redirection. This can be useful for local\ndevelopment and may have some valid usage in production, but should be used\nonly with care after auditing a module to ensure its behavior is valid.
Similar to \"exports\" in package.json, dependencies can also be specified to\nbe objects containing conditions which branch how dependencies are loaded. In\nthe preceding example, \"http\" is allowed when the \"import\" condition is\npart of loading it.
A value of null for the resolved value causes the resolution to fail. This\ncan be used to ensure some kinds of dynamic access are explicitly prevented.
Unknown values for the resolved module location cause failures but are\nnot guaranteed to be forward compatible.
\nRedirected dependencies can provide attenuated or modified functionality as fits\nthe application. For example, log data about timing of function durations by\nwrapping the original:
\nconst original = require('fn');\nmodule.exports = function fn(...args) {\n console.time();\n try {\n return new.target ?\n Reflect.construct(original, args) :\n Reflect.apply(original, this, args);\n } finally {\n console.timeEnd();\n }\n};\nUse the \"scopes\" field of a manifest to set configuration for many resources\nat once. The \"scopes\" field works by matching resources by their segments.\nIf a scope or resource includes \"cascade\": true, unknown specifiers will\nbe searched for in their containing scope. The containing scope for cascading\nis found by recursively reducing the resource URL by removing segments for\nspecial schemes, keeping trailing \"/\" suffixes, and removing the query and\nhash fragment. This leads to the eventual reduction of the URL to its origin.\nIf the URL is non-special the scope will be located by the URL's origin. If no\nscope is found for the origin or in the case of opaque origins, a protocol\nstring can be used as a scope.
Note, blob: URLs adopt their origin from the path they contain, and so a scope\nof \"blob:https://nodejs.org\" will have no effect since no URL can have an\norigin of blob:https://nodejs.org; URLs starting with\nblob:https://nodejs.org/ will use https://nodejs.org for its origin and\nthus https: for its protocol scope. For opaque origin blob: URLs they will\nhave blob: for their protocol scope since they do not adopt origins.
Setting an integrity to true on a scope will set the integrity for any\nresource not found in the manifest to true.
Setting an integrity to null on a scope will set the integrity for any\nresource not found in the manifest to fail matching.
Not including an integrity is the same as setting the integrity to null.
\"cascade\" for integrity checks will be ignored if \"integrity\" is explicitly\nset.
The following example allows loading any file:
\n{\n \"scopes\": {\n \"file:\": {\n \"integrity\": true\n }\n }\n}\nThe following example, would allow access to fs for all resources within\n./app/:
{\n \"resources\": {\n \"./app/checked.js\": {\n \"cascade\": true,\n \"integrity\": true\n }\n },\n \"scopes\": {\n \"./app/\": {\n \"dependencies\": {\n \"fs\": true\n }\n }\n }\n}\nThe following example, would allow access to fs for all data: resources:
{\n \"resources\": {\n \"data:text/javascript,import('fs');\": {\n \"cascade\": true,\n \"integrity\": true\n }\n },\n \"scopes\": {\n \"data:\": {\n \"dependencies\": {\n \"fs\": true\n }\n }\n }\n}\n