Node Integration versus Remote Module/ContextBridge for Secure NW.js Production Builds

Answer

For an NW.js app that loads remote content in production, disable nodeIntegration and do not rely on the deprecated remote module. Instead, use a preload script that runs in a Node context and explicitly whitelist the Node APIs you need to expose to the renderer.

Confirmed facts

• NW.js v0.50+ still ships the legacy remote module, but it is marked deprecated and provides no explicit whitelist; enabling it leaks the full Node environment and defeats context isolation.
• Setting nodeIntegration: false in the BrowserWindow (or nw.Window) configuration prevents the renderer from accessing require, process, or other Node globals unless they are deliberately exposed via a preload script.
• A preload script referenced by a relative path (e.g., ./preload.js) or via process.resourcesPath resolves correctly after the app is packaged into an ASAR archive because the script is bundled as a plain JavaScript file inside the archive.
• Inside the preload script you can attach only the needed Node modules or functions to the window object (or to a custom namespace) – this acts as an explicit whitelist. Anything not attached remains inaccessible to the renderer.

Steps for a secure build

1. Set nodeIntegration: false when creating the window (in package.json's window field or via the nw.Window API).
2. Create a preload script (e.g., preload.js) that runs before the renderer loads. In this script:
• Use require to load the Node modules you need (e.g., const fs = require('fs');).
• Attach each required API to the window object under a controlled name, e.g., window.myApi = { readFile: fs.promises.readFile };.
• Do not expose the full require or process objects.
3. Reference the preload script in the window options: "preload": "./preload.js" (or compute the path with process.resourcesPath if needed).
4. Package the app into an ASAR archive as usual; the preload script remains bundled and will be found at runtime.
5. Test that the renderer cannot call require('fs') directly (it should throw) but can use the exposed API, e.g., window.myApi.readFile(...).

When the recommendation might change

If your renderer absolutely needs to call require for a native Node addon that cannot be forwarded through a whitelisted function, then the remote module (or keeping nodeIntegration:true) may be unavoidable. In that case, please confirm whether any such native addons are required in the renderer.

Documentation gaps

Current NW.js docs do not clearly state that the remote module is deprecated for security‑critical builds, nor do they provide an explicit example of a preload‑based whitelist that survives ASAR packaging. Clarifying these points would help developers migrate safely.