Content security policy and firewalls

Every host to allow in your website's content security policy, your office network and your mail filter, and how to recognise Subcontext calling your systems.

This page lists every address Subcontext uses, for whoever looks after your website's security headers, your network or your email filtering. Each embed's guide also lists what that embed needs.

Your website's content security policy#

A content security policy (CSP) is a header that tells the browser which other sites your pages may load things from or talk to. If your website doesn't send one, skip this section.

Every embed#

All the embeds need these two:

Directive Allow Why
script-src https://js.subcontext.com The embeds' scripts.
connect-src https://subcontext.com Everything the embeds ask Subcontext for.

Each embed's extras#

Directive Allow Needed by
connect-src wss://subcontext.com The webchat, quote form and form guide (their live connection, and talking in the browser). The lead form, only if it opens a chat after sending. Not the nurture widget or WebMCP.
style-src 'unsafe-inline' The quote form and form guide. The lead form instead takes your page's nonce on its script tag (or 'unsafe-inline'). The nurture widget only in older browsers. The webchat and WebMCP need nothing.
img-src https: The webchat and form guide, for the agent's picture and images in replies. To be stricter, allow https://subcontext.com and https://*.s3.eu-west-1.amazonaws.com (images you upload are served from there, after a redirect), plus any other image addresses your agent's replies use.
frame-src https://subcontext.com The webchat's payment forms.
frame-src https://www.youtube.com https://player.vimeo.com The webchat, if your agent shares videos.
media-src https: The webchat, if your agent shares video files.
script-src https://js.stripe.com The quote form, if the journey takes payment.
connect-src https://api.stripe.com The quote form, if the journey takes payment.
frame-src https://js.stripe.com https://hooks.stripe.com https://checkout.stripe.com The quote form, if the journey takes payment: card fields, the bank's card check (3-D Secure) and Direct Debit setup.
script-src, frame-src https://challenges.cloudflare.com The lead form, if it uses the Cloudflare Turnstile bot check.
font-src, style-src your font hosts The quote form, if you give it fonts to load.

The embed guides explain each in more detail: webchat, quote form, lead form, form guide, nurture and WebMCP.

Everything at once#

This policy covers all the embeds and payments. Merge it into your existing policy instead of replacing it:

text 
script-src  'self' https://js.subcontext.com https://js.stripe.com https://challenges.cloudflare.com;
connect-src 'self' https://subcontext.com wss://subcontext.com https://api.stripe.com;
style-src   'self' 'unsafe-inline';
img-src     'self' data: https:;
media-src   'self' https:;
frame-src   https://subcontext.com https://js.stripe.com https://hooks.stripe.com https://checkout.stripe.com https://challenges.cloudflare.com https://www.youtube.com https://player.vimeo.com;

Talking in the browser#

The webchat runs inside your page, not in a frame, so it uses your page's permission to use the microphone. If your site sends a Permissions-Policy header, it must allow the microphone for your own pages (microphone=(self)), or visitors can't talk to the agent.

Sites on your own domain#

Pages of a Subcontext site served through your own domain set their own policy, so you don't add anything for them. Your CDN must pass every request through to Subcontext.

Your office network#

If your team's browsers go through a web filter or proxy, allow these for the Subcontext dashboard:

Host What for
subcontext.com (HTTPS and WebSocket, wss://subcontext.com/cable) The dashboard, and live updates to the inbox.
js.subcontext.com, cdn.subcontext.com Scripts, styles and media.
*.s3.eu-west-1.amazonaws.com Files and images you upload and download.
fonts.googleapis.com, fonts.gstatic.com Fonts.
js.stripe.com, api.stripe.com Billing and payment settings.
connect.facebook.net, www.facebook.com, graph.facebook.com, staticxx.facebook.com Connecting WhatsApp (only while you do it).
inquiry.withpersona.com The phone number compliance form.
accounts.google.com, apis.google.com Connecting Google Calendar or Google Sheets.

Your email filter#

  • Email from Subcontext is sent through Amazon SES, from subcontext.com or from your own sending domain. If your mail filter holds unknown senders, allow mail from subcontext.com, so your team gets its notifications.
  • Email to your agents goes to addresses at inbound.subcontext.com. If your mail system blocks forwarding to outside addresses, allow forwarding to that domain (see Receive email into an agent).

When Subcontext calls your systems#

Subcontext calls your systems when you set up an integration or a webhook (see Integrations), and when it checks a website or short link domain.

  • There's no fixed list of IP addresses. Subcontext doesn't publish the addresses its requests come from, and they can change. Don't rely on an IP allowlist to let Subcontext in.
  • Check credentials instead. Give each integration its own API key, token or password, and check it on every request. Webhooks can be signed with a secret you set. Check the X-Subcontext-Signature header.
  • Your endpoint must be public HTTPS. Subcontext only calls addresses that use https:// and resolve to public IP addresses. Hosts that resolve to private ranges, localhost, or names ending .local or .internal are refused.
  • Don't rely on the user agent to recognise Subcontext's requests. It isn't fixed.
  • Domain checks come to https://<your hostname>/__verify/<token>. If a firewall or bot protection sits in front of your CDN, let that path through.

Stuck, or something missing?

Get in touch and a person on the team will help.

Contact us