Azure Functions Node Worker Security

Azure Functions Node.js Worker Security

Perform a focused security analysis of the requested change or flow. Also apply the azure-functions-node-worker domain skill so findings respect the Host-worker contract and Node.js process model.

Read threat-model.md when analyzing a trust-boundary crossing, dynamic code loading, transport, process-wide state, or dependency change.

Security Standard

A security finding requires all of the following:

1. A security property that should hold.
2. An attacker or less-trusted source that can influence data or control flow.
3. A concrete source-to-sink path in this repository.
4. Preconditions that are possible under the documented deployment model.
5. A credible confidentiality, integrity, availability, or isolation impact.
6. Evidence that existing validation or an upstream trust guarantee does not already prevent the path.

Do not report a vulnerability from a sensitive API name alone. Separate confirmed vulnerabilities from defense-in-depth improvements, hardening suggestions, and questions about the Host contract.

Required Workflow

1. Set Scope and Security Properties

Identify the changed behavior, not only changed files. State which properties matter:

• only the intended Host endpoint can control the worker
• only intended function-app code and exports are loaded
• RPC and invocation data retain type, size, and binding boundaries
• credentials and sensitive data do not cross logs or error responses
• one app, specialization, or invocation does not inherit unintended state from another
• malformed or adversarial input cannot crash, hang, or exhaust the worker disproportionately
• generated artifacts and shipped dependencies correspond to reviewed sources

For a code-writing task, analyze the proposed data flow before editing and re-check the actual diff afterward. For a review task, inspect changed lines plus the nearest validators, callers, sinks, and tests.

2. Establish the Threat Actor

Choose the relevant source explicitly:

• function-app author controlling package metadata and executable app files
• external caller controlling trigger or binding data delivered through the Host
• privileged Azure Functions Host sending lifecycle, metadata, and invocation messages
• local process or network actor able to reach a configured worker endpoint
• package publisher or compromised build input

The Host is normally a privileged peer, not an anonymous remote client. Findings that require a compromised Host must be labeled defense in depth unless the supported boundary says otherwise.

3. Trace Source to Sink

Trace concrete values through the worker:

source -> parser/decoder -> validation/canonicalization -> state/converter -> sensitive sink -> observable impact

Review the applicable sinks:

• require, dynamic import, entry-point lookup, package main, and glob expansion
• filesystem access, path resolution, drive/UNC handling, symlinks, and working-directory changes
• process.env, process listeners, termination, module cache, timers, and global app state
• protobuf decoding/verification, converters, buffers, JSON, binding maps, and response construction
• gRPC endpoint selection, credentials, message-size limits, and stream error handling
• logs, exception messages/stacks, hook-transformed logs, and sanitization
• retries, synchronous work, unbounded collections, recursion, allocation, and user-controlled output
• package manifests, lockfiles, generation scripts, webpack, NuGet packaging, and pipelines

4. Test the Hypothesis

Try to disprove each candidate issue before reporting it:

• find upstream validation or a Host guarantee
• verify whether the source is actually attacker-controlled
• verify whether the sink is reachable in production
• distinguish process-wide behavior that is intentional for one function app
• construct the smallest safe regression test for the claimed boundary

Test boundary values appropriate to the flow, including missing/null values, maximum sizes, duplicate or unexpected map keys, malformed encoded data, mixed path separators, absolute/drive-relative/UNC paths, traversal segments, symlinks, circular error objects, secret-bearing URLs, concurrent invocations, specialization during outstanding work, and hooks that throw or never settle.

Do not create exploit files outside the test workspace, access real credentials, contact production endpoints, or print discovered secret values. Use synthetic values and repository test fixtures.

5. Validate the Fix or Finding

Run the nearest security regression first, then the domain-required checks. Typical focused commands are:

npx mocha -r ts-node/register "test/errors.test.ts"
npx mocha -r ts-node/register "test/loadScriptFile.test.ts"
npx mocha -r ts-node/register "test/eventHandlers/FunctionEnvironmentReloadHandler.test.ts"
npx mocha -r ts-node/register "test/eventHandlers/InvocationHandler.test.ts"

For dependency changes, inspect the manifest and lockfile diff and run npm audit --omit=dev when a lockfile and network access are available. Never run npm audit fix, replace packages, or accept a major update automatically. Verify runtime reachability and review install/build scripts instead of treating an advisory count as proof of exploitability.

Complete applicable repository checks:

npm run lint
npm test
npm run build

Use npm run webpack for bundle or package changes and npm run host-sanity for Host-boundary changes when prerequisites are available.