App

Changelog · — Monocle Assess & Enforce, policy decision logging, health alerts, and Install with AI.

Security

Content Security Policy

A Content Security Policy (CSP) is a security standard that helps prevent cross-site scripting (XSS), clickjacking, and other code injection attacks by specifying which sources of content are allowed to load on your page. If your application uses a CSP, you will need to add the Monocle domains to your policy for the script to function correctly.

Required directives

Monocle requires the following CSP directives:

DirectiveValue
script-srchttps://*.mcl.io https://mcl.spur.us
connect-srchttps://*.mcl.io wss://*.mcl.io https://mcl.spur.us wss://mcl.spur.us

Example

Both hosts are needed. Monocle serves from *.mcl.io and from mcl.spur.us depending on which integration and SDK version you use, and a policy is checked against the host being requested, so allowing only one blocks the other. Keep the *.mcl.io entries wildcarded: the loader redirects to a randomized subdomain, so a narrowed host will fail.

You can add CSP headers directly in your HTML using a <meta> tag. Merge the Monocle directives with any existing directives in your policy.

html
<meta
http-equiv="Content-Security-Policy"
content="script-src 'self' https://*.mcl.io https://mcl.spur.us; connect-src 'self' https://*.mcl.io wss://*.mcl.io https://mcl.spur.us wss://mcl.spur.us;"
/>

If a directive above is missing from your existing policy, it is currently falling back to default-src. Adding it stops that fallback, so carry over whatever default-src allowed (usually 'self') alongside the Monocle hosts, or you will block your own same-origin requests.

Verifying your CSP

After updating your policy, verify that Monocle is loading correctly:

  1. Open your browser's developer tools and check the Console tab for any CSP violation errors.
  2. Look for errors naming mcl.io or mcl.spur.us. These indicate that the directives have not been applied correctly.
  3. In the Network tab, confirm that the Monocle requests are completing successfully. Depending on your integration and SDK version these go to mcl.spur.us, *.mcl.io, or both.

Directives Monocle cannot add its script to

Integrations that add the Monocle script for you, such as the Cloudflare Worker, merge the Monocle domains into your existing policy as your pages are served. Two directives make that impossible, and a page carrying either is served exactly as your origin sent it, with no Monocle script on it:

DirectiveWhy
require-trusted-types-for / trusted-typesGoverns how scripts may reach the page. The integration cannot know which policy name your pages will accept.
sandboxRestricts the document itself, including whether its scripts may run at all.

You have two options:

  • Drop the directive on the protected hostname. Other hostnames on the same zone keep their policy, since the Worker is bound to one hostname.
  • Add the Monocle script to your pages yourself. A script tag written into your own HTML is inserted by the parser, so Trusted Types does not apply to it, and you keep the directive. Your pages still need the required directives above.

A custom domain does not help with these two directives, although it does solve the more common CSP problem of a policy that will not admit a third-party host. Trusted Types governs how a script reaches the page rather than where it came from, so serving Monocle from your own subdomain is refused in the same way.

The Health check on your integration's page in the dashboard reports this, naming the directive it found.