This blog post provides some information about securing JSON payloads used by JavaScript virtual machines with the Orchex Enterprise Orchestration Engine (EOE). System security, especially for something as vital, fundamental, and potentially all-encompassing, is an area where it always helps to be paranoid. Based on our research on this topic, and knowing how software is crafted these days, we are actually more concerned about the potential misuse of such JSON in systems other than Orchex, which we implement in Rust to invoke JavaScript virtual machines with limited capabilities and in limited contexts. Additionally, even without validating the JSON, we were unable to get the virtual machine to invoke any JavaScript, but this may be a “limitation” of the quick_js virtual machine currently in use. We will continue researching, but we would appreciate any comments on this topic and our specific considerations. Note that LLMs have been helpful both in understanding the issues and in developing relevant attack techniques for “testing” purposes.
Update 15.Dec.2025: After years of frustration with WordPress, I am finally abandoning this blog. The content will likely stay here for some time, but new content will appear here:
For context and background information about Enterprise Orchestration Engines, see:
There are three cases where the orchestration engine may pass JSON that should be validated to a JavaScript virtual machine:
- When it invokes a processor, the orchestration engine sets the orchex_payload variable in a JavaScript virtual machine to the arbitrary JSON payload passed with the request, which could contain JavaScript code.
- Orchestration sets the orchex_context variable to include that payload and other data from the HTTP request, including arbitrary query string parameters and HTTP headers that could contain JavaScript code.
- When an orchestration processor invokes a webservice API, it sets the orchex_response variable to the result of that API call, which could contain JavaScript code.
Each of these is a potential security concern, as it may be able to craft payloads and HTTP requests such that the server invokes contained JavaScript.
If the JSON is not valid, then it cannot be de-serialized into a Rust object, which mitigates significant potential attack vectors. It does not seem possible to construct a valid JSON payload that would cause the virtual machine to execute JavaScript in the JSON values assigned to variables. Unfortunately, nor does it seem possible to allow all possible valid payloads without the possibility of JavaScript in such values. Orchex will do its best to validate JSON values anyway, defaulting to extreme limitations. In addition to not providing a security guarantee, this is almost certainly unnecessary overhead. Luckily, there is no runtime significantly faster than Rust.
Even if JSON values cannot contain JavaScript, there are still risks. The JSON payload could contain keys such as __proto__, constructor, prototype, __defineGetter__, and otherwise that could cause JavaScript to invoke code in the values associated with those keys. Therefore, to ensure that the JSON is safe, the orchestration engine must ensure that the JSON does not contain such keys. That’s a pretty straightforward problem to address in Rust code.
Another concern is how the application uses the values in the JSON. While this is primarily a responsibility of the implementation, and therefore something against which the orchestration engine itself cannot possibly defend, we can think about some specific use cases.
Orchex has the ability to invoke Handlebars templates, which means passing a template string and some JSON to a function that merges them.
The template can contain arbitrary JavaScript. Customers may implement solutions that pass the template string as part of the payload, which the orchestration engine in turn would pass to Handlebars. This would present risks using Handlebars implemented in JavaScript, but Orchex actually uses a Rust port of Handebars. There is no way for the Rust implementation to invoke Rust, JavaScript, or any other code in the template.
Possibly the most important security factor to consider is controlling what clients, applications, and systems can invoke orchestration processes. This goes far beyond securing JSON from JavaScript, including prevention of DOS attacks that could impact service while “racking up” (pun intended) hosting costs. While we recommend using existing facilities such as firewalls, whitelisting, cloudy mitigation providers, and other external techniques to address most of these vectors, we must address these concerns before anything built with Orchex can reach production.
deliverystack.net 