Security and CSP

Allowed origins

Tiketo registers exact production and staging origins for each client ID. Agreed localhost patterns can also be enabled for staging. The browser sends its Origin with the config request. Disallowed origins receive 403, and configuration responses never use wildcard CORS.

The client ID is public and does not authenticate a user. Authorize sensitive work in your application or backend.

Content Security Policy

The loader, widget code, stylesheet, fonts, and conversation traffic use the selected Tiketo embed origin. For production, merge this baseline into your existing policy:

Content-Security-Policy:
  script-src 'self' https://chatbot.tiketo.cloud;
  style-src 'self' 'unsafe-inline' https://chatbot.tiketo.cloud;
  font-src 'self' https://chatbot.tiketo.cloud;
  connect-src 'self' https://chatbot.tiketo.cloud wss://chatbot.tiketo.cloud;
  img-src 'self' data: https:;

Use https://staging.chatbot.tiketo.cloud while testing staging, plus wss://staging.chatbot.tiketo.cloud in connect-src. The conversation endpoint comes from the client configuration, so this policy applies to every embed version, including pinned ones. If you use the MCP integration with a server on another origin, add that origin to connect-src as well. All widget scripts and styles are self-hosted on the selected Tiketo origin. Keep style-src 'unsafe-inline' because the widget applies runtime styles inside its shadow DOM. If img-src does not allow https:, add each image host configured for your chatbot or components.

With a nonce-based policy, add the nonce to the inline queue snippet and keep the selected Tiketo origin in script-src. The loader creates the widget <script> dynamically and does not copy your nonce. The loader does not publish Subresource Integrity metadata or require crossorigin. Pin an immutable version and rely on HTTPS and CSP; an SRI attribute cannot cover the loader’s nested assets.

Treat data as untrusted

The embed validates actions and components against versioned schemas. Your code must still:

• escape payload data with textContent or your framework. Never interpolate it into innerHTML;
• authorize sensitive operations and validate them again at the trust boundary;
• never put secrets, credentials, or personal data in launch context;
• use only the allowed image and link forms, and narrow your site CSP where possible.

For state-changing handlers, follow the authorization and idempotency guidance.

MCP credentials and transcripts

The optional MCP integration sends host-supplied authentication headers from the browser directly to the configured MCP endpoint. Header providers run for each request. Their values are not persisted, logged, included in action results, or sent to Tiketo’s Worker or the conversation service. The MCP endpoint must authenticate and authorize the signed-in user.

MCP tool arguments and results are conversation data, not credentials. The conversation service processes them, and they can appear in transcripts. Keep the allowlist small and include only suitable fields. Write tools require in-chat confirmation before the first network request.

Tool results can contain untrusted third-party instructions. They cannot expand the tool allowlist or execute a write on their own. Every write still needs explicit user confirmation. MCP requests include opaque conversation and call IDs so the server can match its audit log to a transcript without logging host credentials.

For retention and subprocessors, see MCP integration.