Skip to main content

​
Browser security headers

The SDK renders the chat UI in a blob: iframe generated by the host page. Safari applies host-page framing CSP to that generated iframe document, so restrictive framing headers can block the SDK even though no network request is made for the blob: URL. Products that embed the SDK must allow their own blob: iframe:
Do not use frame-ancestors 'none' or X-Frame-Options: DENY on SDK-enabled pages. This Safari-specific CSP behavior blocks the SDK’s generated iframe document before the chat app can start.

​
Browser permissions

If your host page sets a restrictive Permissions-Policy header, you must allow microphone for voice input to work; otherwise it will be blocked inside the iframe. The SDK iframe inherits your page’s origin, so allowing self is sufficient:
If your page does not set a Permissions-Policy header at all, no configuration is needed.

​
What the SDK does for you

  • Static iframe HTML. Configuration is delivered via postMessage, not an inline script, so CSP hashes stay stable across config changes and the SDK’s own header close button uses no inline handlers.
  • Namespaced storage. All localStorage keys are prefixed libra:.
  • No cookies on API calls. Session cookies are not sent with SDK API requests.
  • Safe citation opens. Only http(s) citation URLs are opened; other schemes are blocked.
  • Proxy URL validation. In proxy mode proxy.url must be same-site with the page (or localhost during development); init() throws otherwise to prevent SSRF through a misconfigured host.