Show Menu
TÓPICOS×

Política de segurança de conteúdo (CSP)

A principal meta de uma Política de segurança de conteúdo (CSP) é impedir ataques de script entre sites (XSS, cross site scripting attacks). Isso acontece quando o navegador é enganado para executar conteúdo mal-intencionado que parece vir de uma fonte confiável, mas vem de outro lugar. O CSP permite que o navegador verifique (em nome do usuário) se o script realmente vem de uma fonte confiável.
O CSP é implementado adicionando o cabeçalho HTTP do Content-Security-Policy às respostas do servidor. Leia mais sobre CSP no site da Mozilla Developer Network https://developer.mozilla.org/pt-BR/docs/Web/HTTP/CSP

Problemas a serem solucionados

Os sistemas de gerenciamento de tags foram projetados para carregar scripts dinamicamente. O CSP foi projetado para bloquear esses scripts carregados dinamicamente porque eles podem causar problemas de segurança.
Se você quiser que o Launch funcione com seu CSP, há dois desafios principais a serem superados:
  • A fonte da biblioteca do Launch deve ser confiável. Se essa condição não for atendida, a biblioteca do Launch e outros arquivos JavaScript necessários serão bloqueados pelo navegador e não serão carregados na página.
  • Os scripts incorporados devem ser permitidos. Se essa condição não for atendida, as ações de regra do Código personalizado serão bloqueadas na página e não serão executadas adequadamente.
Se quiser usar o Launch e tiver um CSP em vigor, será necessário corrigir esses problemas sem marcar outros scripts como confiáveis incorretamente. Aumentar a segurança tem um preço: aumentar a quantidade de trabalho da sua parte.

Fontes confiáveis

Se sua biblioteca for de auto-hospedagem, a fonte da biblioteca provavelmente se encontra em seu próprio domínio. Você pode especificar que o domínio de host é uma fonte segura como esta:
script-src 'self'
Se você a Adobe hospeda a biblioteca (com o host Gerenciado pela Adobe), sua biblioteca será mantida em assets.adobedtm.com. Nesse caso, suas políticas deverão ter essa aparência:
script-src 'self' assets.adobedtm.com
Você deve especificar o self como um domínio seguro para não interromper nenhum script que já esteja carregando, mas também precisa que assets.adobedtm.com esteja listado como seguro ou a biblioteca do Launch não será carregada na página.
Você pode ler mais sobre fontes confiáveis no site da Mozilla Developer Network .

Scripts incorporados

Os scripts incorporados apresentam um desafio para o CSP porque não são permitidos por padrão. Há duas opções para permitir scripts incorporados:
  • Permitir todos os scripts incorporados (menos seguro)
  • Permitir por nonce (boa segurança)
A especificação do CSP contém detalhes para a terceira opção usando hashes, mas essa abordagem não é viável para uso com um TMS de qualquer tipo por várias razões, algumas delas muito complicadas.

Boa segurança - Nonces

Este método envolve generar um nonce e adicioná-lo ao CSP e a cada script incorporado. Quando o navegador recebe uma instrução para carregar um script incorporado contendo um nonce, compare o valor do nonce com o que está contido no cabaçalho do CSP. Se corresponder, o script é carregado.
Este nonce deve ser alterado a cada novo carregamento de página.
Há um pré-requisito muito importante: você deve carregar a biblioteca do Launch de forma assíncrona . Isso não funciona com uma carga síncrona da biblioteca do Launch (o que resulta em erros e regras do console não serem executados corretamente).
Adicione seu nonce ao CSP hospedado pela Adobe, dessa forma:
script-src 'self' assets.adobedtm.com 'nonce-2726c7f26c'
É necessário dizer ao Launch onde encontrar o nonce. O Launch o utiliza ao carregar um script incorporado. Para que o Launch use o nonce ao carregar o script, é necessário:
  1. Crie um elemento de dados que faça referência ao nonce (onde quer que você o coloque na camada de dados).
  2. Configure a Extensão principal e especifique o elemento de dados usado.
  3. Publique seu elemento de dados e as alterações na Extensão principal.
Uma observação adicional: isso somente lida com o carregamento do código personalizado. Ele não lida com o que você faz em seu código personalizado. É possível que você escreva um código personalizado que não esteja em conformidade com seu CSP, caso em que o CSP tem prioridade. Por exemplo, se você usar o código personalizado para carregar um script incorporado ao anexá-lo ao DOM, o Launch não poderá localizar ou adicionar o nonce corretamente, de modo que determinada ação de código personalizado não funcionará conforme esperado.

Baixa segurança - Permitir incorporado

Se a opção acima não funcionar para você, você pode informar ao CSP para permitir todos os scripts incorporados. Essa é a opção menos segura, mas também é mais fácil de implementar e manter.
Novamente, supondo que a Adobe gerencie a hospedagem e você marque o domínio assets.adobedtm.com como uma fonte confiável, seu CSP terá algo semelhante a:
script-src 'self' assets.adobedtm.com 'unsafe-inline'
Para obter mais informações sobre como permitir scripts incorporados, consulte https://developer.mozilla.org/pt-BR/docs/Web/HTTP/Headers/Content-Security-Policy/script-src no site MDN.