CSP recomendada

Se o seu site publica uma Content Security Policy, o widget do Data Lead precisa aparecer nela. Esta página lista o que ele carrega, para onde ele fala e o que costuma quebrar.

Cada site tem uma política diferente. Trate o exemplo abaixo como ponto de partida: some as diretivas do Data Lead à sua política existente, não substitua a sua por esta.

O que o widget carrega e para onde fala

São cinco arquivos, todos do mesmo host de CDN: uma entrada de script-src cobre todos. Só um deles é condicional — o replay.js sobe apenas para quem consentiu no modo completo (veja "A cadeia de scripts"). Já o behavior-perf.js sempre sobe, mas só depois que o behavior.js termina de carregar — é um atraso de sequência, não uma condição.

As rotas públicas usadas em connect-src, para quem precisa auditar o tráfego:

A connect-src casa por origem, não por caminho: uma entrada com o host da aplicação autoriza as cinco. A tabela existe para auditoria, não para você listá-la rota a rota.

Os endereços de CDN e de aplicação podem ser diferentes em contas com domínio próprio: confira o endereço que aparece no snippet em Instalação, ele é a fonte da verdade para o seu site.

O host do avatar é o armazenamento do projeto Data Lead, não o domínio da aplicação: copie-o da URL da imagem que aparece em Personalização (clique com o botão direito no avatar e escolha "Copiar endereço da imagem") e use esse host em img-src.

Política de exemplo

Content-Security-Policy:
  script-src  'self' 'nonce-{{nonce}}' https://cdn.datalead.datastone.com.br https://challenges.cloudflare.com;
  connect-src 'self' https://app.datalead.datastone.com.br https://challenges.cloudflare.com;
  img-src     'self' data: https://*.supabase.co;
  style-src   'self' 'unsafe-inline';
  frame-src   'self' https://challenges.cloudflare.com;

Atenção ao snippet embutido. O código de instalação é um <script> dentro da sua página, e uma script-src que só lista hosts — como a do exemplo — não autoriza código embutido: com ela sozinha o widget não carrega, nem o balão aparece. Escolha um dos dois caminhos: dê um nonce ao snippet, como na seção "Se a sua política é estrita" (preferível, porque mantém a política estrita), ou acrescente 'unsafe-inline' à script-src — o que enfraquece a proteção contra injeção de script na sua página inteira, não só no Data Lead.

Notas sobre cada linha:

• script-src — obrigatório. Sem ele nada carrega: o launcher não aparece. Uma entrada de host cobre os cinco arquivos, inclusive o que sobe condicionalmente (replay.js) e o que sobe com atraso (behavior-perf.js).
• connect-src — obrigatório. Sem ele o chat carrega mas não conversa, nenhum evento de navegação chega ao painel (a verificação de instalação fica presa em "não instalado") e nenhum trecho da gravação de sessão é enviado.
• img-src — só é necessário se você usa avatar do agente. Sem ele o chat funciona, apenas sem a imagem.
• style-src — o chat injeta um elemento <style> dentro do próprio Shadow DOM e um segundo <style> no <head> para posicionar o desafio anti-bot. Em políticas estritas isso exige 'unsafe-inline' em style-src, ou um nonce que o widget não tem como receber hoje.
• frame-src e as linhas da Cloudflare — só fazem sentido se o desafio anti-bot estiver habilitado na sua conta. Ele pode não estar habilitado na sua conta; fale com o suporte.

worker-src não é necessário. O Data Lead não cria nenhum Web Worker: a compressão dos trechos da gravação usa CompressionStream("gzip"), uma API da própria thread principal, e não há new Worker em lugar nenhum do carregador. Se você viu worker-src numa especificação antiga do produto, ela está desatualizada — acrescentar a diretiva não quebra nada, mas não resolve nada também, e procurar um bloqueio de worker-src é caçar fantasma.

Antes de publicar a política no site, teste-a numa página de homologação com o snippet instalado e o console do navegador aberto: uma diretiva faltando aparece como erro Content Security Policy e o chat deixa de abrir sem outro sintoma. Os pontos que mais falham são style-src (estilos do Shadow DOM) e as linhas da Cloudflare quando o anti-bot está ligado.

A cadeia de scripts e o strict-dynamic

O Data Lead carrega os arquivos em cascata, cada um injetando o próximo com document.createElement("script"). É por isso que uma política estrita precisa de atenção extra: o nonce da requisição vale para a tag que você escreveu, e não é herdado automaticamente pelas tags que o produto cria depois.

Para essa cadeia funcionar, a sua script-src precisa de uma das duas coisas:

1. o host da CDN listado (é o caso da política de exemplo acima) — cada tag injetada casa com o host e é autorizada por conta própria; ou
2. 'strict-dynamic' junto do nonce — a confiança do snippet se propaga por toda a cascata, e o host deixa de ser necessário (com 'strict-dynamic', os navegadores ignoram as entradas de host da script-src).

O que não funciona é uma script-src só com 'nonce-…', sem o host da CDN e sem 'strict-dynamic': o snippet roda, você vê o balão do chat, e mesmo assim os níveis 2 a 5 são recusados um a um.

O nível 5 falha calado. O replay.js é injetado numa tag async, e quem consome o resultado é o painel, não a página. Se a CSP recusar esse arquivo, o site do visitante continua perfeito, o chat continua conversando e nada avisa: só a tela Analytics → Gravações fica vazia. Se você habilitou a gravação de sessão e ela não aparece, confira a CSP antes de abrir chamado.

Se a sua política é estrita (nonce e strict-dynamic)

O snippet do Data Lead é um <script> inline que injeta um segundo script. Numa política com nonce, o snippet precisa carregar o nonce da requisição:

<script nonce="{{nonce}}">
  /* snippet do Data Lead */
</script>

Com 'strict-dynamic' na script-src, os scripts que o carregador injeta herdam a confiança do snippet em toda a cascata — inclusive o replay.js, que está no quinto nível. connect-src, img-src e style-src continuam valendo e precisam das entradas da tabela acima.

Content-Security-Policy:
  script-src  'nonce-{{nonce}}' 'strict-dynamic' https: 'unsafe-inline';
  connect-src 'self' https://app.datalead.datastone.com.br https://challenges.cloudflare.com;
  style-src   'self' 'unsafe-inline';
  img-src     'self' data: https://*.supabase.co;
  frame-src   'self' https://challenges.cloudflare.com;

https: e 'unsafe-inline' na primeira linha são o retrocompatível recomendado pelo próprio padrão: navegadores que entendem 'strict-dynamic' os ignoram; os que não entendem caem neles em vez de bloquear tudo.

Como saber o que está bloqueado

1. Abra o site com o console do navegador na aba Console. Violações de CSP aparecem com o texto "Refused to load…" ou "Refused to connect…", nomeando a diretiva.
2. Vá para a aba Rede e filtre por datalead: você deve ver ds.js, e alguns segundos depois behavior.js, behavior-perf.js e widget.js. O replay.js só aparece nas sessões que a gravação alcança — consentimento completo, sem Do Not Track/GPC e dentro da amostragem do site.
3. Se preferir testar sem bloquear ninguém, publique a política em modo de relatório (Content-Security-Policy-Report-Only) antes de aplicá-la de verdade.

Sintomas típicos:

Um detalhe que evita caça a fantasma: o Data Lead é fail-open no anti-bot. Se a Cloudflare estiver bloqueada pela sua política, o envio segue mesmo assim — o desafio não é o que impede a conversa.

Veja também

• API JavaScript do loader
• Shadow DOM e estilos
• Solução de problemas

Precisa de ajuda?

Fale com o suporte da Data Stone pelo canal combinado com a sua conta. Envie a sua política atual e as mensagens de violação copiadas do console.