Node-Remote Whitelist Behavior in Production Builds

Node-Remote Whitelist Behavior in Production Builds

When an NW.js app is run in development mode, any loaded page—including those from remote URLs—has automatic access to Node.js APIs. However, after packaging the application, the default sandbox prevents Node.js integration for remote content unless the page’s origin is explicitly listed in the node-remote array of package.json. This discrepancy often causes local, unpacked builds to work while the distributed executable fails to expose require, process, and other globals.

The node-remote feature was introduced in NW.js v0.50.0 to give developers fine‑grained control over which remote origins may use Node.js. The current documentation does not clarify how pattern matching behaves, whether sub‑domains are automatically granted access, or the security implications of using broad patterns such as *.

Given this context, the following questions remain:

1. Does node-remote support wildcard patterns or only exact origin matches?
2. If a parent domain is listed, are all its sub‑domains automatically allowed?
3. What are the security consequences of setting node-remote to * in a production build?