Page History

...

As you can see from the above example, SecurityException is thrown when "eval" was called with a String or a FileReader. But, if you pass a URLReader, nashorn will associate that URL with the script and therefore security permissions are granted as per your security policy. This allows trusted scripts be granted with more permissions.

load and loadWithNewGlobal builtin

...

functions

Nashorn supports 'load' builtin function. This can be called from a script to load another script from a URL or a File. When script is loaded with "load" call, Nashorn associates URL/File origin to the script and therefore permissions are granted as per the current security policy. This is another way to grant security permissions to specific scripts. loadWithNewGlobal is another builtin function. This can also be used to load script from a URL or a File. Nashorn will associate script URL/File origin to the script and so permissions are granted as per the current security policy.

Summary of various ways of loading/evaluating

...

scripts and security implications:

• javax.script API: . The script code submitted via engine.eval(String) and engine.eval(Reader) are always treated as sandbox code  - except for jdk.nashorn.api.scripting.URLReader. If you pass URLReader, script origin based on that URL associated is used. So, security permissions are based on the script origin URL.
  
  

• Calling ECMAScript "eval" builtin function. In this case, script is treated as "sandbox" and hence gets only sandbox permissions.
  
  
• Calling calling "load" nashorn extension builtin function with a file File/URL- this method and command line method both associate a URL/File origin for the script and hence script URL/File based fine-grained permission can be used. When you run with security manager on, you can specify permissions for specific script URLs or file: URLs
  

• Read string using a java library or otherwise and then calling ECMAScript "eval" builtin function. Script is treated as "sandbox" and hence only sandbox permissions. But, you can generate/modify script programmatically!

• "Calling "load" from a script object as in load({ name: "foo", script: str}) This is equivalent to "eval" - but it associates a name with script and so stack traces will have nice readable name instead of <eval>. "str" may be computed or a literal. It does not matter. But, script is treated as 'sandbox'.
  
  

• Calling loadWithNewGlobal nashorn extension function. This is similar to load [all options are load available]. The difference is that it creates a new EMCAScript global scope and loads your code into that global. This avoids global namespace pollution. If you're going to use require or another module system and your scripts are well-behaved (as modules), you probably don't need this. But, it is useful when no module system exists and you want isolation. Note that security access permission is still only based on script origin urlURL or File if you pass a URL or a File. If you use loadWithNewGlobal as loadWithNewGlobal({ name: "foo", script: str}), the script is treated as a sandbox.
  
  
  
• javax.script API engine.eval(Reader, Bindings) or engine.eval(String, Bindings). This is similar to the other engine.eval methods in that these are sandbox script evaluations unless Reader is a URLReader. But, these methods create/associate a fresh ECMAScript global and load code there [similar to loadWithNewGlobal in that sense]