Segurança e Content Security Policy

A Content Security Policy

O widget não carrega fontes de terceiros nem pixels de rastreamento e não executa eval. Define seus estilos por folhas de estilo construíveis (adoptedStyleSheets) no shadow DOM; elas não são abrangidas por style-src. Por isso, você não precisa de unsafe-inline nem de unsafe-eval.

Com os endereços do reactive.chat:

Content-Security-Policy:
  script-src 'self' https://cdn.reactive.chat;
  connect-src 'self' wss://ws.reactive.chat https://ws.reactive.chat;
  img-src 'self' data: https:;

Com um domínio próprio:

Content-Security-Policy:
  script-src 'self' https://chat.your-company.com;
  connect-src 'self' wss://chat.your-company.com https://chat.your-company.com;
  img-src 'self' data: https:;

As entradas individuais:

• script-src – o local de loader.js. O núcleo (core.<hash>.js) e os módulos carregados depois (tours, texto de privacidade, loja) também vêm dali.
• connect-src com wss:// – a conexão do chat.
• connect-src com https:// – o mesmo endereço novamente: o fallback HTTP, o formulário offline, os uploads de arquivos, o texto de privacidade e o Smart Answer passam por ele. Se essa entrada faltar, você só percebe em redes sem WebSocket; nelas, nenhuma conexão é estabelecida.
• img-src – imagens no chat: logo e avatares (seus endereços https:// ou imagens data:), imagens do card promocional e prévias de anexos (do endereço do chat). Se quiser restringir img-src, inclua pelo menos o endereço do chat e os hosts do logo e das imagens do card. O widget mostra uma imagem bloqueada como linha de arquivo em vez de prévia.

Navegadores antigos sem folhas de estilo construíveis (como Safari anterior ao 16.4) recorrem a um elemento <style>, bloqueado por uma style-src rigorosa. O widget funciona neles, mas sem estilo.

Não é necessário script inline

A instalação consiste apenas em um <script src> com atributos. Suas chamadas próprias (identify, track, open) devem ficar em arquivos de script próprios ou em um script inline com nonce:

<script nonce="R4nd0mN0nc3">
  ReactiveChat('identify', { userId: '4711', userHash: '…', exp: 1792503600 });
</script>

Um modelo sem script inline está em Identificar visitantes.

Subresource Integrity

loader.js não tem número de versão no nome e é atualizado continuamente; um atributo integrity desativaria o chat na próxima atualização. O núcleo é carregado com um hash de conteúdo no nome (Arquitetura). Se sua política exigir SRI, hospede loader.js por conta própria e defina data-rc-ws-url (Início rápido), mas as atualizações também passam a ser sua responsabilidade.

Isolamento da sua página

• Shadow DOM fechado. Seus estilos não alcançam o widget, e os estilos dele não alcançam sua página, nem com resets globais.
• Sem cookies. O widget não define cookies; os IDs ficam no armazenamento do navegador e, sem consentimento, apenas em sessionStorage (Integração de privacidade).
• Sem acesso a campos de formulário. A leitura de texto da página para o assistente nunca lê campos de entrada e não é executada em páginas como conta, checkout e carrinho. Você exclui outras áreas com data-rc-private.
• Dados pessoais são ocultos duas vezes: no navegador antes de uma mensagem sair (números de cartão com verificação de Luhn, IBAN, e-mail, telefone, números fiscais) e no servidor antes do armazenamento. Parâmetros sensíveis de query (email, password, token, key, card …) são removidos dos endereços transmitidos.
• Links e imagens de mensagens e cards são restritos a https://; links javascript: e data: são descartados.

Verificação de origem

A conexão do chat só é aceita a partir dos domínios listados no projeto em Origens permitidas (incluindo subdomínios). Uma página de terceiros que copie sua chave do site recebe origin_denied. Se a lista estiver vazia, não há verificação; portanto, cadastre sempre seus domínios. Detalhes em Transporte.

A chave do site em si não é um segredo; está no código-fonte de todas as páginas.

O que nunca deve estar no navegador

• o segredo de identidade (para userHash) – Identidade
• o segredo do endpoint de dados de clientes rckd_… – Dados de clientes
• o segredo de assinatura do webhook – Webhooks
• chaves de API rc_live_… – API do servidor
• a chave de proxy rcpx_… – Domínio próprio

Nem em um aplicativo, repositório público ou endereço de página.

Proteção contra abuso

O servidor limita conexões, quadros e mensagens por conexão e por endereço e bloqueia após violações repetidas (fechamento 1008). Atrás do seu próprio proxy, só conta por endereço de visitante se a chave de proxy estiver correta; caso contrário, todos os visitantes compartilham o endereço do proxy. Números em Limites e cotas.

A seguir: Domínio próprio