Chilkat.Js is Sandboxed by Default

By default, Chilkat.Js is sandboxed because the core engine provides only a pure ECMAScript runtime and no operating-system APIs. The engine executes JavaScript but has no built-in capability to interact with the outside world unless the embedding application explicitly exposes those capabilities.

In other words, Chilkat.JS runs JavaScript in a closed environment where the only available functionality is the standard JavaScript language and standard library.

However, applications can enable selected Chilkat classes to be used within the Javascript. All Chilkat classes are disabled by default. Prior to running a JavaScript, individual Chilkat classes can be enabled in sandbox, read-only, write-only, or read/write modes.

JavaScript Code can use Chilkat Classes

The host application can choose to enable specific Chilkat classes. These classes provide the only mechanism for JavaScript code running in the sandbox to access resources outside the runtime. For example, if enabled by the host, a Chilkat class can allow JavaScript to interact with the local filesystem or communicate over Internet protocols such as HTTP, SMTP, SSH, etc.

No Built-in OS or Filesystem APIs

The core Chilkat.Js runtime implements only the ECMAScript language:

  • numbers
  • strings
  • arrays
  • objects
  • promises
  • modules
  • etc.

It does not include (non-Chilkat) APIs such as:

  • file I/O
  • networking
  • processes
  • environment variables
  • system commands

For example, this does not exist in default Chilkat.Js:

fs.readFile("file.txt")
fetch("https://example.com")
open("/etc/passwd")

Those APIs are not part of ECMAScript, so the engine simply has no implementation for them.

Therefore, JavaScript code running inside Chilkat.Js cannot read or write files unless the host application explicitly enables the appropriate Chilkat class or classes and allows them to be used in the required mode.

Likewise, JavaScript code cannot communicate over the network unless the host application enables certain Chilkat classes, such as Chilkat.Http or Chilkat.Socket.

Modules

Chilkat.Js does not implement a module loader and therefore cannot dynamically load JavaScript modules at runtime (for example using import statements that resolve to files). Because of this, JavaScript code executed in Chilkat.Js must be provided as a single self-contained script.

To work with code that is organized into multiple modules during development, a developer should use a JavaScript bundler as part of the build process. A bundler takes many JavaScript source files that use import / export statements and combines them into a single output file that can be executed by Chilkat.Js.

The bundler essentially inlines all module code into one script, removing the need for runtime module loading.

Why bundling is required

Because Chilkat.Js:

  • does not read JavaScript files from the filesystem
  • does not implement a module loader
  • does not resolve import paths

all dependencies must be resolved before execution. Bundling ensures that the final script contains everything needed to run.

Typical Secure Embedding Model

A typical QuickJS sandbox architecture looks like this:

Host Application
        │
        │ enable selected Chilkat classes
        ▼
QuickJS Runtime
        │
        ▼
JavaScript Code