JavaScript sandboxing explained

A sandbox must explain how code is prevented from obtaining authority it was not granted. ADsafe explored a language subset and mediated objects; other systems put the boundary in different places.

Objects can carry permission

An object-capability design treats references as a way of granting authority. If code receives a function that writes to a particular output, that function grants the ability to perform that operation. If it receives an unrestricted browser document instead, the authority is much broader. The practical task is to control both the initial references and the references returned later.

The original ADsafe site explicitly connects its restrictions to this model. Guest code avoids most globals and receives selected services through ADSAFE. Its document access goes through a wrapper for a widget subtree. The language restrictions try to prevent code from bypassing that intended route to broader authority.

A naming convention alone cannot do this. A variable called safeDocument is still powerful if it refers to the real document. Likewise, a narrow-looking method can leak authority through a returned object. These are conceptual consequences of following references, not claims that every wrapper library is a sandbox.

ADsafe: restrict the language and expose a small interface

Douglas Crockford’s historical ADsafe project required guests to fit an accepted JavaScript subset. Its original homepage says it did not rewrite guest scripts. The verifier and the runtime performed different jobs: reject unsafe forms before execution, then provide useful controlled services during execution. The root DIV located the permitted content; it did not create a separate browser realm.

This makes ADsafe useful for studying the connection between static checks and runtime APIs. It does not make a saved runtime a current security guarantee. This independent edition explains the historical model and makes no claim of endorsement by Crockford.

Caja: a related capability-based embedding project

Google’s archived Caja project also used an object-capability approach to embedding third-party HTML, CSS and JavaScript. The two projects shared a concern about the authority granted to embedded code, but their accepted languages and enforcement machinery should not be treated as identical. Caja’s own documentation is the source for its design; ADsafe’s rules are not a Caja specification.

Caja’s repository carries a deprecation notice and says security patches are no longer addressed. It belongs in this comparison as a historical related project, rather than as an unqualified recommendation for new deployments. See the Caja project documentation.

SES and compartments: controlled execution contexts

Endo’s SES documentation describes compartments with their own global objects and lexical scopes, alongside frozen shared intrinsics. The conceptual connection is deliberate control of what references and globals code receives. The enforcement arrangement differs from ADsafe’s checked subset and widget DOM facade.

A compartment does not automatically define a web widget DOM interface. A host must still decide what services to endow it with and what those services can reveal. That comparison follows from each project’s documented boundary; it does not establish an API compatibility or migration path. Read the SES documentation for its own requirements.

Iframes: a boundary implemented by the browser

An iframe creates a nested browsing context. Its sandbox attribute applies browser-enforced restrictions, with tokens that selectively relax them. Origin relationships and the chosen tokens matter: an iframe is not isolated merely because it has a border or a separate URL. The HTML standard warns about combining script and same-origin permissions when embedded content shares the parent’s origin.

This boundary differs from granting a callback a mediated subtree interface in the same page. Communication between a frame and its host also needs a deliberate policy. See the HTML standard’s sandbox definition for the normative token behavior.

Compare assumptions before comparing syntax

Ask what code is accepted, where it executes, what objects it initially receives, which checks prevent escape and what host extensions can change. Those questions expose a meaningful difference between the systems without pretending they are interchangeable. Resource consumption, user-interface deception and the safety of privileged services require separate attention too.

For ADsafe specifically, continue with security and limits and guarded property access. They show how the historical design’s authority rules reach all the way into small API choices.