Execution Sandbox — Custom JavaScript

What Is Blocked and Why

Blocked API	Why blocked
`fetch`, `XMLHttpRequest`	Scripts must not make unauthorized network calls. All data arrives through the widget's configured data source, which goes through the App Studio security layer.
`window`, `document`, `navigator`	DOM manipulation could break the App Studio shell, read other widgets' DOM, or leak data across widget boundaries.
`localStorage`, `sessionStorage`, `indexedDB`	Browser storage is shared across the session. Scripts could read auth tokens or other tenants' data stored by the platform.
`eval`, `Function()`	Dynamic code execution bypasses sandbox restrictions.
`setTimeout` / `setInterval` (unbounded)	Unbounded async execution could create resource leaks. Short setTimeout (<100ms) is allowed for deferred micro-tasks.
`import` / `require`	Module loading from arbitrary sources is not permitted.
`process`, `global`	Node.js globals — not relevant in browser, blocked to prevent confusion.

What Happens When Blocked APIs Are Called

If a blocked API is called at runtime:

The sandbox throws a SandboxViolationError
The script execution stops at the point of the violation
A sandbox violation error is logged in the designer's editor output panel
In production, the violation is silently swallowed — the widget continues rendering with no custom JS side effects
Platform administrators can see sandbox violations in the audit log

Execution Time Limit

Scripts have a maximum execution time limit (typically 200ms). Scripts that take longer are terminated:

// OK — simple synchronous computation
function onDataChange(widget, variables) {
  const total = widget.data.rows.reduce((s, r) => s + r.v, 0);
  variables.set('total', total);
}

// PROBLEMATIC — avoid heavy computation on large datasets
// Processing 50,000 rows synchronously may hit the time limit
// Consider filtering at the data source level instead

Sandbox Implementation

The sandbox is implemented using a controlled Function wrapper that replaces the global scope with a proxy object. The proxy exposes only the permitted APIs (widget, variables, actions, context, standard JS builtins) and throws on any property access that isn't on the allowlist.

// Conceptual sandbox execution model
const sandboxedScope = {
  widget,
  variables,
  actions,
  context,
  // Standard JS:
  Array, Object, Math, JSON, Date, String, Number, Boolean,
  parseInt, parseFloat, isNaN, isFinite,
  console: { log: sandboxedConsoleLog },
  // Everything else: throws SandboxViolationError on access
};

const fn = new Function(...Object.keys(sandboxedScope), scriptSource);
fn(...Object.values(sandboxedScope));

Testing for Sandbox Compliance

In the designer editor, click Test to run the script in the sandbox with test data. The output panel shows:

Any sandbox violations caught at test time
console.log output
Execution time for the script
Variables that were set (simulated)

The editor also marks sandbox violations as red underlines in the code using static analysis, so you can fix them before even running the test.

← Triggering Actions Next: Examples →