Security & the trust model.

Two layers, two threat models

The distinction decides which control you need. A cross-site-scripting attempt smuggled into a product name is a Layer 2 problem, and the sanitisers already handle it. A program authored by a prompt-injectable LLM is a Layer 1 problem, and no sanitiser addresses it — you need to narrow the global surface instead.

Which case are you in?

Narrowing the global surface

setGlobalAccessPolicy gates the last step of identifier resolution — the passthrough to the embedding realm. Knowing where that step sits explains both what the policy can reach and what it cannot touch:

1. user state ($name)
2. bindings in scope
3. action declarations
4. user component declarations (PascalCase function)
5. the curated GLOBAL_NAMESPACES fast path
6. the component library
7. cleanup
8. host globals — policy-gated

Two consequences fall out of that ordering. Everything above step 8 is resolved before the policy is consulted, so the policy cannot break it. And a library component always wins over a same-named host constructor — the Text and Map components beat DOM Text and JS Map, under every policy.

import { setGlobalAccessPolicy, getGlobalAccessPolicy } from "aktion-runtime";

setGlobalAccessPolicy("safe");        // data + formatting only
getGlobalAccessPolicy();              // -> "safe"

What "safe" allows

Capabilities a program needs to compute with values — and nothing that grants code execution, DOM access, network access, or persistence:

What "safe" blocks, and why

A custom allow-list

Pass an array when "safe" is the wrong shape — either because you need one more capability, or because you want less. The array is exhaustive: nothing outside it resolves.

// "safe", plus crypto for client-side id generation
setGlobalAccessPolicy([
  "Map", "Set", "Promise", "Intl", "RegExp", "URL", "URLSearchParams",
  "encodeURIComponent", "decodeURIComponent", "atob", "btoa", "console",
  "crypto",
]);

// Stricter than "safe": formatting only, no containers, no console
setGlobalAccessPolicy(["Intl", "RegExp", "parseInt", "parseFloat", "isNaN"]);

A blocked name does not throw — it simply does not resolve, so the expression evaluates as if the identifier were undeclared. Turn on strict while developing to see those lookups reported instead of silently yielding undefined.

What breaks under "safe"

Worth knowing before you flip it, because the failures are quiet rather than loud:

The rule is simply "not in the 46 names above", so treat that table as the allow-list and this one as the common cases — not as an exhaustive deny-list.

Why the policy is not trivially bypassable

Narrowing globals would accomplish nothing on its own, because every lambda a program can write is a real JavaScript function — and f.constructor is Function. So three property names are refused on every access path: dot access, computed access, method-call dispatch, and both write paths.

$f = () => 1
$f.constructor            // undefined — not the Function constructor
$f["cons" + "tructor"]    // undefined — computed access is checked too
$o.__proto__              // falsy
$o.prototype              // undefined

The same three segments (__proto__, constructor, prototype) are refused on state writes, where they would otherwise be a prototype-pollution primitive. A write through them is a silent no-op rather than an error.

The shadow DOM is not a security boundary

<aktion-app> renders into a shadow root, which is easy to mistake for isolation. It is not. A shadow root gives you style encapsulation — the host page's CSS does not leak in, and the component stylesheet does not leak out. It gives you no origin separation: script running inside a shadow root has the host page's full origin privileges, and can read cookies, localStorage, and the rest of the document.

If you need a real boundary, use one the platform actually provides: a cross-origin <iframe> with a restrictive sandbox attribute. Inside the same document, setGlobalAccessPolicy is the control that matters.

The sink-to-sanitiser table

These defend Layer 2 — untrusted values flowing through a trusted program. They are always on; there is nothing to configure. The underlying principle is worth more than the table: every URL-typed prop in the library goes through one of two chokepoints (sanitiseHref for link targets, sanitiseImageSrc for image sources), so the guarantee holds for components added after this page was written.

External links rendered by Link, NavbarItem, and the Markdown renderer carry rel="noopener noreferrer", so the destination cannot read the opener's document.referrer.

Resource bounds

Every one of these limits is data-driven, so without them untrusted data — a 40 MB Markdown blob, an array with a billion entries, a self-nesting component tree — could freeze the host tab. That makes them a security control, not just a performance one.

The failure modes differ, and the difference matters when you are debugging. Over-long Markdown is truncated, so the beginning still renders. Clamped props silently take the ceiling. Budget overruns throw RuntimeBudgetError, which the host surfaces as a banner rather than a hung tab — see Performance for tuning the budget and Error handling for catching it.

Keeping network access under host control

$http({...}) is the vetted network path, and it is the only one left under a "safe" policy. Every request flows through your host's interceptor chain, so auth headers, CORS workarounds, and refresh-token retries stay yours to decide:

app.registerHttpInterceptors({
  onRequest: (req) => ({ ...req, headers: { ...req.headers, Authorization: `Bearer ${token}` } }),
  onResponse: (res) => res,
  onError: (err) => { report(err); throw err; },
});

Use onRequest to enforce a destination allow-list when programs are semi-trusted — the interceptor sees the final URL and can reject it before the request leaves the page. See HTTP for the full contract.

Content-Security-Policy

A CSP hardens the host page. It is useful defence in depth, and the two controls compose neatly here — but only in one direction, so it is worth being precise about which does what.

• The runtime needs no 'unsafe-eval'. It uses neither eval nor new Function; action and effect bodies are interpreted from the AST by a tree-walking evaluator.
• A program can still need it — under the default "all" policy a program may call eval or Function itself. setGlobalAccessPolicy("safe") removes that reachability, which is exactly what makes a script-src without 'unsafe-eval' meaningful. The policy is what earns you the tighter CSP; the CSP does not substitute for the policy.
• Aktion never injects a <script> element and never assigns innerHTML on the live document, so script-src needs no 'unsafe-inline' either.
• style-src does need relaxing. The runtime emits inline style attributes and injects <style> elements, so it needs 'unsafe-inline' or a nonce/hash strategy.

The complete policy — including the style-src, font-src, and img-src directives the renderer actually requires — is in Production & deployment.

Node-side tooling

import { setGlobalAccessPolicy, renderToStaticMarkup } from "aktion-runtime";

setGlobalAccessPolicy("safe");           // before rendering anything untrusted
const html = renderToStaticMarkup(program);

Two more things to know about the SSR path. The $head allow-lists apply there as well — in fact the attribute-name validation exists specifically because the server path emits names outside quotes. And the hydration snapshot it hands back is your job to escape for the <script> context you serialise it into; the runtime does not do that for you.

The build tooling has its own path-confinement story:

• The Vite plugin confines .aktion imports to the Vite project root, so a specifier like ../../../../etc/passwd is refused rather than read — and, under vite dev, rather than served to the browser. The opt-out is aktion({ allowOutsideRoot: true }); use it only for trusted monorepo layouts. See Modules.
• create-aktion turns the project name into a filesystem path, so it rejects control characters, a leading - or ~, absolute paths and drive letters, .. segments, and Windows reserved device names.
• linkProgram takes a caller-supplied module resolver, which means path confinement is your responsibility if you wire your own — the plugin supplies a confined one, but a custom resolver gets no root check for free.

Review checklist

• Can program text reach us from anywhere other than our own repo? If yes → setGlobalAccessPolicy("safe"), set once at host setup.
• Is an LLM's context free of untrusted content? If not, treat prompt injection as a code-execution path.
• Are $http destinations constrained by an onRequest interceptor?
• Does the CSP cover style-src and font-src, not just script-src? (See deployment.)
• Is anything relying on the shadow root for isolation rather than styling?
• Is the Node/SSR process running the same policy as the browser?

Reporting a vulnerability

Report security issues privately — please do not open a public issue first. The repository's SECURITY.md carries the current contact route, the supported-version policy, and the reporting scope, including which behaviours are considered by-design rather than vulnerabilities. Behaviour reachable only under the default "all" policy with attacker-authored program text is in the by-design category — that is the surface setGlobalAccessPolicy exists to close.

Next