[epoberezkin]

I also prefer writing code to DSLs etc. Unfortunately, just writing code doesn't solve the problems mentioned here: https://github.com/JSONScript/jsonscript#problem

Sending code in some existing general purpose or scripting language makes it either difficult/inefficient to parse, or insecure (if, e.g. JavaScript or bash eval is used), or both. Limited privileges only partially protect the host and usually leave some vulnerabilities...

JSONScript is both very easy and efficient to parse (a JSON-Schema is used to evaluate the script) and it is secure because it executes the script in a "sandbox" having access only to those system resources that the host environment explicitly exposed to the interpreter.

My two main use cases are 1) scripted processing on top of existing API (implemented) and 2) proxy allowing scripted processing across multiple APIs in the same location (soon).

[woah]

I still don't understand how this has any security advantages over just sending code. You are sending code, just shoehorning it into a serialization format.

[epoberezkin]

The difference is that general purpose programming languages usually provide full access to the host environment, they are not designed to be received from untrusted environments.

You need to reduce what is allowed, and that is more likely to leave vulnerabilities, than explicitly whitelisting what methods can be called.

I think that any abstraction/DSL, not JSONScript specifically, with a specialised interpreter on the server side is more likely to be secure than processing general purpose language instructions received from the client.

[tony-allan]

The safety of a simple language is appealing.