Security model
The SDK is a browser component inside your application. It defends its own licensing and execution boundaries; everything about who your users are and what they may do stays with you. Use this page to complete a threat assessment without reading the source.
Trust boundaries
| Boundary | Held by | Defends against |
|---|---|---|
| Licence | Offline lease verification against public keys embedded in your build | A build running on an unapproved origin or beyond its licensed capabilities |
| Capability | Signed entitlement policy checked before a gated surface starts | A feature running that the deployment is not licensed for |
| Worker | Worker authorisation guard, verified inside the worker | A worker executing without a valid deployment lease |
| Trusted custom indicator code | Host application review and build pipeline | Unreviewed indicator source executing in the host application |
| Embedded content | Sandboxed provider frames, no markup insertion | A stored drawing introducing script into your page |
What each control does
Lease verification is entirely offline. The lease is an Ed25519-signed token checked in the browser against keys compiled into your build, with the issuer and audience pinned. No runtime request reaches TradeScript, so authorisation adds no availability dependency and leaks no deployment data.
Entitlements are checked before a licensed surface starts, not merely hidden in
the interface. A capability absent from the signed policy fails closed with a
typed authorization.entitlement-denied error.
The public indicator path is layered by ownership. Built-ins are shipped native capabilities; trusted custom indicators are reviewed modules bundled with the host application. The customer SDK does not expose a runtime source compiler or an end-user indicator editor, so host applications should not promise an untrusted-source execution surface.
Embedded content is never inserted as markup. A provider link is extracted from whatever the user pastes and rendered in a sandboxed frame — see Security.
Content Security Policy by feature
Add only what the features you enable require.
| Feature | Directive | Value |
|---|---|---|
| Market data, broker, storage, bootstrap | connect-src | Your data, broker, storage, and application origins |
| Workers | worker-src | 'self', or the exact worker origin you serve |
| Embedded content | frame-src | Each provider origin you permit |
| Chart image export | img-src | data: and blob: |
| SDK styles | style-src | Your origin, or a nonce supplied through the nonce option |
Built-in indicators and trusted custom indicators bundled with your application
need no unsafe-eval. Keep CSP strict and verify the result with browser CSP
reporting active.
Lease revocation
Leases are time-limited and verified offline, so there is no revocation list to consult. A lease remains valid until it expires, up to a maximum of seven days.
The compensating controls are the short lifetime, binding to approved origins, binding to a customer build fingerprint, and the permanent credential never leaving your backend. Where an immediate stop is required, stop issuing leases and remove the build; existing browser sessions lose authorisation at expiry.
Record this exposure window in your risk assessment. Raise it with your deployment contact if your control framework requires immediate revocation.
Recording trading activity
Record-keeping obligations sit with you. The trading controller emits one record for every attempted financial mutation so you can write an audit trail without wrapping each operation yourself.
const trading = sdk.trading.createController(broker, {
onFinancialMutation: (record) => auditSink.write(record),
})
Each record carries the phase, the operation and its risk class, the account and instrument it targets, the host operation identity and origin where the caller supplied one, and the host risk decision that settled it.
| Phase | Emitted |
|---|---|
requested | Before any risk evaluation, so a refused attempt is still recorded |
authorized | The mutation was permitted and proceeds to the broker |
rejected | The host risk boundary refused it |
An observer that throws does not abort the mutation it observes; the failure is reported through the SDK debug log instead. Completed outcomes arrive separately through the trading event stream.
Out of scope
The SDK does not authenticate your users, authorise them against your own permissions, or enforce entitlements over market data. It applies no trading controls beyond those your broker adapter and risk policy define, and it makes no investment decision.
Your application owns hosting, transport security, session management, tenant isolation, market data licensing, regulatory compliance, and the security of every backend the chart talks to.
Related pages
Read Security for embedded content isolation, Data handling for what the SDK stores and transmits, and Supply chain to verify the artifact you deployed.