The boundary breaks when expression data is converted into executable JavaScript inside the application process. At that point, a formula is no longer just business logic. If an attacker can influence the expression or the variables used during simplification, the runtime can execute code with the same privileges as the Node.js service.
Why This Matters for Security Teams
When an untrusted formula reaches NIST SP 800-53 Rev 5 Security and Privacy Controls-style application logic through toJSFunction(), the service stops treating the formula as data and begins executing attacker-influenced code in-process. That shifts the issue from business-rule validation to code execution risk, with the Node.js runtime, file system, secrets, and downstream APIs all potentially in scope. The danger is not limited to obvious payloads; even a seemingly harmless expression can become a bridge into privileged runtime access if the surrounding variables or helper functions are not tightly constrained.
This is especially important because organisations routinely underestimate how often non-human execution paths carry sensitive privilege. The Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges and 80% of identity breaches involved compromised non-human identities such as service accounts and API keys. In practice, many security teams encounter formula injection only after a logging, export, or calculation feature has already been used as an execution path, rather than through intentional testing.
How It Works in Practice
toJSFunction() is dangerous because it converts expression syntax into a callable JavaScript function inside the application process. If the expression source is attacker-controlled, or if trusted code passes attacker-shaped variables into the evaluation context, the boundary between “math” and “code” disappears. That is why current guidance treats expression compilation as an execution-risk problem, not a simple parsing problem.
Defensive control needs to start before compilation and continue through runtime evaluation:
- Reject untrusted formulas unless the grammar is explicitly limited to safe operators and literals.
- Keep evaluation contexts minimal, with no access to globals, constructors, filesystem helpers, or process objects.
- Use allowlisted functions only, and treat any user-supplied helper as hostile by default.
- Prefer sandboxed or isolated evaluation patterns when formulas are necessary for product behavior.
- Log formula origin, evaluation outcome, and unusual execution paths for detection and review.
The operational lesson aligns with NHI governance: the issue is not just the formula, but the privilege of the runtime that evaluates it. The Ultimate Guide to NHIs also highlights that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes in-process execution especially risky if the formula can reach environment variables or cached tokens. The right control objective is to keep untrusted input non-executable and ensure the evaluator cannot see more than the expression truly needs. These controls tend to break down in analytics, reporting, and workflow engines where business users can author formulas but the same service also holds API keys or database credentials.
Common Variations and Edge Cases
Tighter formula controls often increase product friction, requiring organisations to balance user flexibility against the risk of runtime abuse. That tradeoff is real in spreadsheets, billing engines, low-code tools, and embedded DSLs, where teams want expressive formulas but cannot safely expose the full JavaScript runtime.
There is no universal standard for this yet, but current guidance suggests treating every expression feature as a potential code-execution surface. The safest pattern is to separate formula parsing from JavaScript compilation, or to run evaluation in a constrained environment with narrowly scoped inputs. Where that is not feasible, the fallback is strict allowlisting, aggressive validation, and short-lived execution contexts with no ambient authority. For broader identity and secrets context, the Ultimate Guide to NHIs remains a useful baseline for understanding how excessive privilege magnifies the blast radius. In practice, the edge case that hurts most is a “safe” formula feature added to a service that already has cloud credentials, because the evaluator inherits everything the application can reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 | Untrusted formula execution can expose NHI secrets and service-account privileges. |
| OWASP Agentic AI Top 10 | A1 | Formula-to-code conversion mirrors unsafe tool execution and untrusted input handling. |
| CSA MAESTRO | SEC-04 | MAESTRO stresses runtime isolation for autonomous or delegated execution paths. |
| NIST AI RMF | AI RMF supports governing high-risk execution surfaces and their downstream impact. | |
| NIST CSF 2.0 | PR.AC-4 | Least privilege is central when evaluation code can reach app secrets and APIs. |
Treat any expression compiler as an execution tool and block attacker-controlled inputs from runtime authority.
Related resources from NHI Mgmt Group
- What breaks when switch management interfaces are exposed to untrusted networks?
- How should security teams choose authentication for Node.js apps that may become B2B products?
- What breaks when a Node.js auth stack does not support organisation-aware access?
- What breaks when spreadsheet formulas can reach host execution?
