src: Wldp (Windows code integrity) integration

[rdw-msft]

This PR adds experimental Windows-only integration with Windows Defender Application Control (WDAC) so Node.js can participate in OS-managed code integrity enforcement.

Motivation

Node.js's threat model treats the code the runtime is asked to execute as trusted. This change does not alter that threat model or introduce a new Node.js security boundary.

Instead, this adds an opt-in defense-in-depth feature for Windows environments that already use WDAC to control what code may execute on the system. In those deployments, Node.js can cooperate with the operating system's code integrity policy before loading certain files intended for execution.

The goal is to help operators and application authors align Node.js with OS-level integrity policy and reduce the risk of post-deployment tampering of application files.

More specifically, this integration helps users and operators gain stronger assurance that the JavaScript, JSON, and native addon files Node.js loads have not been modified from the version signed and shipped by the application author. In environments that enable this feature, Node.js can ask Windows to validate that code being loaded still matches the integrity metadata established at build or release time and is trusted by system policy.

What is WDAC?

Windows Defender Application Control (WDAC) is a Windows security feature that allows administrators to define code integrity policies for a system. These policies determine which code is trusted to run, using mechanisms such as digital signatures, file hashes, certificates, and related policy configuration.

For traditional binaries like EXEs and DLLs, Windows can usually enforce those checks directly. For dynamic runtimes like Node.js, the operating system cannot always determine whether a file being opened is intended for execution, so the runtime must explicitly cooperate with WDAC.

With this change, Node.js can ask WDAC whether files it is about to load for execution are permitted by policy.

WDAC policies can also provide tamper-resistant application-specific settings. These settings let administrators opt Node.js into code integrity enforcement and optionally disable interactive execution modes such as REPL and --eval.

What this PR does

When WDAC policy enables the Node.js-specific EnforceCodeIntegrity setting, Node.js consults WDAC before loading:

• .js
• .json
• .node

files through the module loaders.

If the WDAC policy indicates that the file is not allowed to execute, Node.js throws ERR_CODE_INTEGRITY_VIOLATION instead of proceeding.

When WDAC policy enables DisableInteractiveMode, Node.js also disables execution paths intended for interactive or ad hoc code entry, including:

• -e
• --eval
• REPL usage

In those cases Node.js throws ERR_CODE_INTEGRITY_BLOCKED.

If these policy settings are not enabled, behavior is unchanged.

Scope and security model

This feature is Windows-only and disabled by default.

It should be understood as a hardening and policy-enforcement integration for managed environments, not as a general-purpose sandbox or a replacement for application security boundaries.

In particular:

• Node.js still trusts the application code it is asked to run.
• This feature helps verify that deployed code artifacts have not been modified since signing time, according to WDAC policy.
• This does not make untrusted application input safe.
• This does not turn Node.js into a sandbox for adversarial code.
• This does not redefine which classes of bugs are considered Node.js vulnerabilities under SECURITY.md.

Instead, it gives administrators a way to require that code loaded by Node.js comply with WDAC policy when they explicitly opt into that behavior.

WDAC APIs used

This PR uses the following WDAC interfaces:

• WldpCanExecuteFile
  Checks whether a file is allowed to execute under WDAC policy.

• WldpGetApplicationSettingBoolean
  Reads Node.js-specific WDAC application settings where supported.

• WldpQuerySecurityPolicy
  Provides fallback policy-setting lookup on older Windows versions.

Audiences

There are two audiences for this feature:

1. Application developers, who prepare and distribute code and related catalog/signature material.
2. System administrators / operators, who configure WDAC policy and choose whether Node.js should enforce these checks.

Node.js only performs these checks when WDAC policy is configured to request them.

Signing model

For script and module content that Node.js is expected to execute, application authors can generate a Windows catalog (.cat) containing file hashes and sign it with a certificate trusted by WDAC policy.

This gives operators and end users stronger confidence that the files Node.js executes in production are the same files the application author produced and signed at build or release time, rather than modified copies introduced later.

For example:

New-FileCatalog -CatalogFilePath ./MyApplicationCatalog.cat -Path ./MyApplicationRelease/

The resulting catalog can then be signed using PowerShell or signtool.exe and deployed according to WDAC guidance.

Documentation

User-facing documentation for this feature is added in doc/api/code_integrity.md.

Other Questions

What about Linux?

At the moment, there is no unified code integrity subsystem that provides similar cooperative interfaces for interpreters on Linux. There are proposals in-flight and we're tracking this work and hope to keep the implementation as similar as possible across OSs.

Continued maintenance
We believe this is a valuable security feature and are committed to maintaining it. However, we would like to receive confirmation from the Node.js maintainers that this is a feature that they are willing to adopt before we dedicate more resources to this effort. To that effect, I will not complete this PR until we have confirmed resources on our end (that is, people/teams in addition to myself) to support the feature.

Other references

Official WDAC documentation
WLDP Developer Documentation

[nodejs-github-bot]

Review requested:

• @nodejs/gyp
• @nodejs/loaders
• @nodejs/startup

[rdw-msft]

@RafaelGSS - opening this PR as suggested from our conversation. Please let me know if there's anything else I should do to get eyes on this PR! Thanks

[anonrig]

This is the same pull request I've blocked 2 years ago. What's the reason for closing that and opening a new pull-request? #54364

[rdw-msft]

This is the same pull request I've blocked 2 years ago. What's the reason for closing that and opening a new pull-request? #54364

Hey @anonrig, my apologies for any confusion. I didn't interpret your comments as a rejection of the PR.

I opened this after discussion with the security WG in the hopes that this would put it in front of more eyes for review. Additionally, the Node.js threat model had changed since opening the other PR, and I wanted to reframe this change in the context of the current threat model. From discussions I've had with the security WG, I think we generally agree this a useful security seatbelt, but the question of whether the TSC was willing to accept it was still unknown.