Script Security

Consider this scenario: a user has write access to NODE_A but no access to NODE_B. Without security controls, that user could create a transformation script on a DCI belonging to NODE_A and use FindNodeObject to read data from NODE_B, bypassing access controls.

The server configuration variable Scripts.RestrictWriteAccess (enabled by default) is the primary script security control. When enabled, the server attaches a read-only security context to scripts executed in server-side contexts — about 19 in total, including:

Scripts running in these contexts can read object data but cannot modify objects (for example, set custom attributes or change object properties).

To prevent this, NXSL object lookup functions such as FindNodeObject accept a "current node" context object. When trusted object checking is enabled (see below), the function returns a reference to the target object only if the context object appears in the target object’s trusted objects list; if the context object is omitted or not trusted, the function returns null. When trusted object checking is disabled, the context argument may be null and no restriction applies.

For example, if $node refers to NODE_A and the script calls FindNodeObject($node, "NODE_B"), then NODE_A must be in the trusted objects list of NODE_B for the call to succeed.

In most script contexts (transformation scripts, event processing policy scripts, etc.), the predefined variable $node serves as this context object. It refers to the node on behalf of which the script runs — the DCI owner for transformation scripts, the event source for EPP scripts, and so on.

By default, trusted object checking is not enforced. For environments requiring strict access control, set server configuration variable Objects.Security.CheckTrustedObjects to 1. The change takes effect immediately — no server restart is required.

When enabled, object lookup functions will return null for any target object where the context object is not in the trusted objects list.

Scripts executed on behalf of a management client user (for example, via Execute Server Script on an object) run under the calling user’s security context, with that user’s object access rights enforced. Editing scripts in the Script Library requires the "Manage script library" system access right.

The exec command of the server debug console runs NXSL scripts by name. The server configuration variable DebugConsole.AllowedScriptLocations is an ordered, comma-separated list of locations searched left to right; the first match wins. The token @library refers to the server script library; any other entry must be an absolute directory path (searched non-recursively; non-absolute entries are skipped with a warning). The default value is @library. When this variable is empty, the exec command is disabled.