Node.js Application Security Hardening

Parent: JavaScript and Node.js · Published reference · snapshot 2026-09-08 · skill lang-js-ts/references/nodejs-security-hardening.md

↓ Facts as markdown all context files

This reference is the consolidated Node.js security playbook: the threats that

These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.

Overview

This reference is the consolidated Node.js security playbook: the threats that are specific to running JavaScript on a server with full OS access, and the defenses Node ships for them. It is organized threat → defense so you can go from a symptom ("untrusted JSON reaches a merge", "user input reaches child_process") straight to the mitigation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
Node's own threat model sets the boundary: Node trusts the code it is asked to run and the OS environment it runs in. Everything here is about defending the line between trusted application code and untrusted external input - request bodies, query strings, JSON, transcripts, file paths, third-party packages. It is not about sandboxing untrusted code (Node explicitly does not do that). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
This file owns the application-layer attack surface. Several adjacent concerns live in sibling references and are deferred, not duplicated: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- Permission-Model mechanics (the full --allow-fs-read/--allow-net/SEA flag matrix) → nodejs-typescript-and-runtime-features. Here we cover only why the model is defense-in-depth, not a sandbox. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- Package-manager workflows (lockfile/audit/workspace mechanics) → nodejs-package-management-supply-chain. Here we cover supply chain as risk. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- HTTP security headers (Helmet, CSP, HSTS, CORS) → http-security-headers. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- Web Crypto / vault / encryption-at-rest → webcrypto-vault-reviewer. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- OAuth/OIDC/session auth flows → web-auth-patterns. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
- **Event-loop / ReDoS-blocking mechanics** → nodejs-concurrency-internals. Here we cover ReDoS only from the defense angle. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]
The mental model: validate untrusted input at the boundary, deny shells and dynamic eval, freeze what should be immutable, and treat every dependency as untrusted code. Defense-in-depth - no single flag makes a Node app safe. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#overview]

1. Prototype pollution (CWE-1321)

JavaScript objects inherit from Object.prototype. If an attacker can write a key named __proto__, constructor, or prototype into an object built from untrusted data, they mutate that shared prototype - and every object in the process suddenly carries the injected property. The classic sink is an insecure recursive merge / deep-clone / extend (CVE-2018-16487 in lodash) or a query-string parser that auto-vivifies nested keys (?__proto__[isAdmin]=1). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
Impact: ranges from logic corruption and DoS to privilege escalation and, via a gadget, full RCE (a polluted .env/.shell property read by a later child_process call - see concept 6). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
Defenses (layer them): [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- Validate against a schema (Ajv/zod) at the boundary - the strongest fix; reject unexpected keys with additionalProperties: false. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- Use null-prototype objects for dictionaries: Object.create(null) (no __proto__ to pollute) or a Map instead of an object-as-dictionary. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- Object.freeze(MyClass.prototype) / Object.freeze(Object.prototype) to block writes to a specific prototype. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- --disable-proto=throw (or =delete) removes the Object.prototype.__proto__ accessor process-wide - throw raises ERR_PROTO_ACCESS on access, delete removes it entirely. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- A JSON.parse reviver that drops __proto__/constructor keys; check ownership with Object.hasOwn(obj, key), never inherited lookups. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]
- Avoid hand-rolled recursive merges on untrusted data; if unavoidable, skip the three magic keys explicitly. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#1-prototype-pollution-cwe-1321]

2. Injection (command, path, eval, SQL/NoSQL)

Command injection is the highest-severity Node-specific sink. child_process.exec() / execSync() spawn a shell (/bin/sh) and the Node docs warn verbatim: "Never pass unsanitized user input to this function. Any input containing shell metacharacters may be used to trigger arbitrary command execution." Defense: prefer execFile() or spawn(), which run the binary directly without a shell by default, and pass arguments as a separate array (spawn('git', ['log', userRef])) so metacharacters are never parsed. Keep shell: false (the default) - enabling shell: true re-introduces the exact exec vulnerability. Never build a command string by concatenating input. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#2-injection-command-path-eval-sqlnosql]
eval() / new Function() / vm with untrusted strings is direct RCE - OWASP calls it inherently a remote-code-execution vulnerability. Don't evaluate user input; use a parser/lookup table instead. vm is not a security sandbox. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#2-injection-command-path-eval-sqlnosql]
Path traversal: untrusted input flowing into fs.* enables ../../etc/passwd file inclusion. Normalize with path.resolve(), then assert the result startsWith the intended base directory; reject otherwise. Decode and strip ../null bytes before use. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#2-injection-command-path-eval-sqlnosql]
SQL/NoSQL injection lives at the app layer: always use parameterized queries / prepared statements (driver placeholders), never string-built SQL. For MongoDB, reject object-typed values where a scalar is expected ({$gt:''} operator injection from query strings) and cast inputs to their expected type. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#2-injection-command-path-eval-sqlnosql]

3. Hardening flags & runtime defenses

Node ships process-level flags that shrink the attack surface as defense-in-depth: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#3-hardening-flags-runtime-defenses]
The Permission Model is defense-in-depth, not a security boundary. The Node docs are explicit: "The permission model implements a 'seat belt' approach … It does not provide security guarantees in the presence of malicious code. Malicious code can bypass the permission model and execute arbitrary code." It "trusts any code it is asked to run." So --permission is useful to prevent trusted code (and its dependencies) from accidentally touching the filesystem or network - a containment layer, not a jail for untrusted code. (The --allow-* flag matrix, scoping, and SEA mechanics are deferred to nodejs-typescript-and-runtime-features.) Also: don't enable experimental features in production unless you accept the breaking-change risk. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#3-hardening-flags-runtime-defenses]

4. Secrets & configuration hygiene

Keep secrets in the environment, not in source. Read from process.env; never commit .env files or hard-coded API keys/tokens (CWE-552). Add .env to .gitignore and use an allowlist (files in package.json, .npmignore) so a npm publish doesn't leak them - verify with npm publish --dry-run. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#4-secrets-configuration-hygiene]
--env-file caveat: --env-file=.env loads vars into process.env, and it also parses Node-configuring vars like NODE_OPTIONS. The docs warn Node "will not sanitize or perform validation on the user-provided configuration, so NEVER use untrusted configuration files." A writable .env is therefore a code-exec vector (it can inject NODE_OPTIONS). --env-file is also not subject to Permission-Model restrictions. Use a real secrets manager for production. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#4-secrets-configuration-hygiene]
Never put secrets in logs or error responses. Redact tokens/passwords/keys before logging; don't echo stack traces or err.message containing connection strings to clients. Centralize redaction in the logger. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#4-secrets-configuration-hygiene]
process.env hygiene: read each secret once at startup into a typed config object; don't pass the whole process.env into child processes or templates (a prototype-pollution gadget can poison it - concept 6). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#4-secrets-configuration-hygiene]

5. Dependency & supply-chain risk (CWE-1357)

Most of a Node app's code is third-party and runs with full privilege. Treat the dependency tree as an attack surface: [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]
- npm audit + CVE response: scan regularly; for a flagged CVE, upgrade to the fixed version (or apply an override) and re-test. Don't ignore transitive advisories. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]
- Install-script risk: postinstall/preinstall scripts run arbitrary code at install time. For untrusted or audited installs use npm install --ignore-scripts (or npm config set ignore-scripts true) and allowlist the few packages that legitimately need a build step. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]
- Dependency confusion: if your build resolves from both a private and the public registry, an attacker can publish a public package with your internal name and win. Defense: publish internal packages under an @your-scope/, register that scope publicly even if unused, and pin the scope to the private registry in .npmrc (@your-scope:registry=…). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]
- Lockfile integrity: commit package-lock.json (it records exact versions and the resolved registry + integrity hash) and install with npm ci, which fails on any lockfile/package.json mismatch. Guard against lockfile poisoning in review. (Lockfile/workspace workflow mechanics → nodejs-package-management-supply-chain.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]
- Keep Node patched: track Node.js security releases and run a supported (Active LTS or Maintenance) line; EOL versions get no security fixes. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#5-dependency-supply-chain-risk-cwe-1357]

6. Request-layer risks (SSRF, ReDoS, smuggling, deserialization)

SSRF (server-side request forgery): any server-side fetch/undici/http call to a user-controlled URL can be steered at internal services or the cloud metadata endpoint 169.254.169.254 to steal credentials. Node's built-in fetch has no SSRF guard. Defense: allowlist permitted hosts/schemes; resolve the hostname to IP and reject private/reserved ranges (loopback/private/link-local/ULA/IPv4-mapped) before connecting; disable or re-validate redirects (a 302 can point inward); beware DNS-rebinding/TOCTOU - validate at connect time (libraries: request-filtering-agent, ssrf-req-filter). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#6-request-layer-risks-ssrf-redos-smuggling-deserialization]
ReDoS (regex denial-of-service): a regex with catastrophic backtracking (nested quantifiers like (a+)+$, overlapping alternations) hangs on a crafted input. Defense angle: avoid such patterns, cap input length, prefer a linear engine (RE2 / node:re2), and screen patterns with safe-regex / vuln-regex-detector. (Why it stalls the whole process - the event-loop blocking mechanics - is in nodejs-concurrency-internals.) [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#6-request-layer-risks-ssrf-redos-smuggling-deserialization]
HTTP request smuggling (CWE-444): ambiguous Content-Length/Transfer-Encoding framing lets a request slip past a front-end. Don't set insecureHTTPParser: true; normalize at the proxy; prefer end-to-end HTTP/2. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#6-request-layer-risks-ssrf-redos-smuggling-deserialization]
Unsafe deserialization: JSON.parse is safe for data, but libraries that deserialize functions (e.g. node-serialize ≤0.0.4 unserialize()) execute attacker-supplied IIFE payloads → RCE. Never deserialize untrusted input with a function-capable format; restrict to JSON + schema validation. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#6-request-layer-risks-ssrf-redos-smuggling-deserialization]

Practical patterns

Validate at the boundary, once. Run every external payload through an Ajv/zod schema with additionalProperties:false before it touches business logic - this closes prototype pollution, type-confusion NoSQL injection, and oversized-field abuse in one place. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]
Ban the shell. Lint for child_process.exec/execSync and shell:true; standardize on execFile/spawn with argument arrays. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]
Run with --disable-proto=throw (cheap, high-value) and consider --frozen-intrinsics once you've confirmed your polyfills load via --require. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]
Wrap untrusted text (transcripts, Slack, case bodies, anything fed to an LLM or template) in an escaped envelope so it can't be interpreted as control input - the same discipline as parameterizing a query. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]
Gate outbound URLs through a single SSRF-filtering agent so no code path can fetch an arbitrary user URL directly. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]
npm ci in CI, --ignore-scripts for untrusted installs, and a scheduled npm audit + Node-version check so patch cadence isn't manual. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#practical-patterns]

Anti-patterns

Deep-merging untrusted JSON with a hand-rolled or old-lodash merge and no schema - the #1 prototype-pollution foothold. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
child_process.exec('cmd ' + userInput) or flipping shell:true "to make it work" - arbitrary command execution. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
eval/new Function on request data, or trusting vm as a sandbox. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
Committing .env, logging full error objects with secrets, or loading an untrusted --env-file (it can inject NODE_OPTIONS). [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
Treating --permission as a sandbox for untrusted code - it is a seat belt for trusted code; malicious code bypasses it. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
Fetching a user-supplied URL server-side with no allowlist / private-range block - SSRF to 169.254.169.254. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
node-serialize.unserialize() (or any function-deserializing format) on untrusted input - instant RCE. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]
Running an EOL Node version or ignoring npm audit advisories. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#anti-patterns]

Troubleshooting

Prototype pollution slipped through schema validation → the validator ran after the merge, or allowed additionalProperties; validate first and set additionalProperties:false. Confirm with ({}).polluted === undefined after the request. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]
--frozen-intrinsics breaks a dependency → a library mutates a built-in; load required polyfills via --require/--import (they run before the freeze) or drop the flag for that service - it's experimental and root-context only. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]
execFile still runs a shell → you passed shell:true or a single command-line string; pass the binary + an args array with shell:false. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]
SSRF filter bypassed → likely DNS rebinding (TOCTOU) or an IPv6-mapped/redirect bypass; re-validate the resolved IP at connect time and disallow redirects to new hosts. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]
Regex still hangs after switching libraries → the pattern is still backtracking-prone; move to RE2 (linear) and cap input length. For why one blocked regex freezes all requests, see nodejs-concurrency-internals. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]
npm audit flags a transitive dep with no direct fix → use an overrides entry to force the patched version, then re-audit and test. [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#troubleshooting]

References

Node.js - Security best practices (prototype pollution, monkey-patching, secure heap, HTTP smuggling, supply chain, permission model, secrets): https://nodejs.org/en/learn/getting-started/security-best-practices [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
Node.js - CLI flags (--frozen-intrinsics, --disable-proto, --secure-heap, --permission, --env-file): https://nodejs.org/api/cli.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
Node.js - Permission Model ("seat belt" / not-a-sandbox, threat model, limitations): https://nodejs.org/api/permissions.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
Node.js - child_process (exec vs execFile/spawn, shell option, shell-injection warning): https://nodejs.org/api/child_process.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
OWASP - Node.js Security Cheat Sheet (command injection, eval, path traversal, ReDoS, request-size limits): https://cheatsheetseries.owasp.org/cheatsheets/Nodejs_Security_Cheat_Sheet.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
OWASP - SSRF Prevention in Node.js (allowlist, private-range block, metadata endpoint): https://owasp.org/www-community/pages/controls/SSRF_Prevention_in_Nodejs [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
Snyk - Preventing insecure deserialization in Node.js (node-serialize, IIFE RCE): https://snyk.io/blog/preventing-insecure-deserialization-node-js/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
Snyk - Detect and prevent dependency confusion attacks on npm: https://snyk.io/blog/detect-prevent-dependency-confusion-attacks-npm-supply-chain-security/ [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
nodejs/undici - SSRF protection in undici / native fetch (no built-in guard): https://github.com/nodejs/undici/issues/2019 [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]
OWASP - Prototype Pollution Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Prototype_Pollution_Prevention_Cheat_Sheet.html [archived source: https://llms-explorer.com/sources/mdb-context-hub/nodejs-security-hardening/#references]

Where this helps

Building any Node.js service that accepts untrusted JSON, request bodies, or file paths from outside, deciding where to put schema validation, path normalization, and null-prototype dictionaries to close the input boundary. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Reviewing code that shells out via child_process.exec/execSync or deserializes external data, where the choice between execFile with an argument array vs. exec with string concatenation is the difference between safe and remote-code-execution. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Auditing a dependency tree before a release, deciding whether to run with --ignore-scripts, check for dependency confusion on scoped packages, and confirm the lockfile is committed and installed with npm ci. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Hardening a service that makes outbound requests to user-supplied URLs, where an SSRF filter is needed to keep a fetch call from being steered at the cloud metadata endpoint or an internal service. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Project ideas

Build a boundary-validation middleware that runs every external payload through an Ajv/zod schema with additionalProperties:false before it reaches business logic, closing prototype pollution and NoSQL type-confusion in one place. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build an SSRF-filtering HTTP agent that allowlists permitted hosts and schemes, re-validates the resolved IP at connect time, and blocks the 169.254.169.254 metadata endpoint, so no code path in the app can fetch an arbitrary user-supplied URL directly. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a CI lint rule that flags child_process.exec/execSync and shell:true usage, forcing a migration to execFile/spawn with argument arrays. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Build a secrets-hygiene checker that scans logs and error responses for redaction gaps and verifies process.env secrets are read once into a typed config object rather than passed whole into child processes or templates. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Common mistakes

Deep-merging untrusted JSON with a hand-rolled or old-lodash merge and no schema validation: the number-one prototype-pollution foothold, since the merge can write __proto__ or constructor into the shared Object.prototype. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Building a shell command by string-concatenating user input into child_process.exec(), or flipping shell:true to make it work: this is the highest-severity Node-specific injection sink. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Treating Node's Permission Model (--permission) as a sandbox for running untrusted code: the docs are explicit that it's a seat belt for trusted code, and malicious code can bypass it entirely. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
Loading an untrusted --env-file: Node does not sanitize or validate it, so a writable .env can inject NODE_OPTIONS and effectively become a code-execution vector. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Known issues

Node's built-in fetch has no SSRF guard at all: any server-side call to a user-controlled URL needs an explicit allowlist and private-range block layered on top. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
--frozen-intrinsics is experimental and root-context only, and it can break a dependency that mutates a built-in unless that dependency's polyfills load via --require/--import before the freeze runs. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
The Permission Model's own documentation states it provides no security guarantees against malicious code; it only shrinks the attack surface for trusted code that might accidentally misbehave. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.
An SSRF allowlist can still be bypassed via DNS rebinding (TOCTOU) or a redirect to a new host, since the hostname was validated at request time rather than reconfirmed at connect time. [source] — AI-suggested, synthesized from this pack's existing facts — not extracted from a source document.

Children

Prototype pollution (attack + defenses) (frontier)
Injection in Node (command/path/eval/SQL-NoSQL) (frontier)
Hardening flags & runtime defenses (incl. Permission Model as defense-in-depth) (frontier)
Secrets & configuration hygiene (frontier)
Dependency & supply-chain risk (frontier)
Request-layer risks (SSRF, ReDoS, smuggling, unsafe deserialization) (frontier)

Frontier under this node: Dependency & supply-chain risk, Hardening flags & runtime defenses (incl. Permission Model as defense-in-depth), Injection in Node (command/path/eval/SQL-NoSQL), Prototype pollution (attack + defenses), Request-layer risks (SSRF, ReDoS, smuggling, unsafe deserialization), Secrets & configuration hygiene

← the whole tree · 3D view· how to read this page