Silverlight Security Sandbox

Analogy categoryAnalogies

The Browser Sandbox Model

Silverlight applications run inside a partial-trust sandbox hosted by the browser plugin: the in-browser CLR blocks direct file system access, prevents launching external processes, and restricts network calls to the originating domain by default. This mirrors the .NET Code Access Security model but applied to a plugin context, so a rogue XAP downloaded from a random website cannot simply read files off the user's disk or silently phone home to an arbitrary server the way a native executable could.

🏏

Cricket analogy: It's like a visiting team being confined to the away dressing room and boundary rope rather than allowed to wander into the home team's strategy meeting or the groundskeeper's shed — access is deliberately fenced off.

Isolated Storage and Cross-Domain Access Policies

Instead of writing to arbitrary paths on disk, Silverlight apps persist local data through IsolatedStorageFile, a virtualized storage area scoped per-application and per-user with a default quota around 1MB, which the app can request to increase via IsolatedStorageFile.IncreaseQuotaTo with user consent. Making network calls to a domain other than the one hosting the XAP requires that target server to publish a clientaccesspolicy.xml (or a compatible crossdomain.xml) at its root, explicitly opting in to cross-domain requests from Silverlight clients — without it, the WebClient or HttpWebRequest call fails with a security exception.

🏏

Cricket analogy: It's like a player's personal locker in the dressing room — they can store their own gear there, but if they want to borrow the physio's equipment from another team's setup, that team has to explicitly authorize it first.

xml

<!-- clientaccesspolicy.xml served from the ROOT of the target domain, e.g. https://api.example.com/clientaccesspolicy.xml -->
<?xml version="1.0" encoding="utf-8"?>
<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="SOAPAction">
        <domain uri="http://myapp.example.com"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

Elevated Trust for Out-of-Browser Applications

When a user installs a Silverlight app out-of-browser and the manifest requests elevated trust, the sandbox boundaries loosen considerably: the app gains access to System.IO for arbitrary file paths (not just isolated storage), can invoke COM automation objects such as Excel or Word via AutomationFactory, and can bypass the cross-domain policy check entirely. This trade-off mirrors giving a browser extension broad host permissions — it enables legitimate line-of-business scenarios like reading local spreadsheets, but it means the app is no longer meaningfully sandboxed from the rest of the operating system.

🏏

Cricket analogy: It's like promoting a promising domestic player straight into the national team's inner circle with full access to team strategy — powerful for legitimate talent, but risky if the vetting was rushed.

Elevated-trust out-of-browser applications can read and write anywhere on the local file system and drive COM automation objects, effectively behaving like a native desktop application once installed. Never grant elevated trust to a XAP from an untrusted source, since the sandbox protections that make browser-hosted plugins relatively safe no longer apply once elevated trust is in effect.

Silverlight's in-browser CLR runs applications in a partial-trust sandbox with no direct file system or process access by default.
IsolatedStorageFile provides per-app, per-user virtualized local storage with a small default quota that can be increased with user consent.
Cross-domain network calls require the target server to publish a clientaccesspolicy.xml or crossdomain.xml opting in to Silverlight requests.
Out-of-browser apps can request elevated trust, unlocking full file system access and COM automation via AutomationFactory.
Elevated trust bypasses the normal cross-domain policy check entirely, which widens both capability and risk.
The sandbox model mirrors .NET Code Access Security but is enforced by the browser plugin host at runtime.