Content Security Policy e headers

Se o seu checkout usa Content Security Policy (CSP), ela precisa permitir o snippet do Proteside. O dashboard não gera uma CSP para você: esta página lista o que o SDK usa de fato no navegador, para você incluir na política da loja.

Diretivas necessáriasCopiar link da seção

Sem connect-src para app.proteside.com, o SDK carrega e roda, mas nenhum evento chega ao dashboard. Sem a permissão opcional para as origens dos scripts, o SDK não calcula o hash desses scripts: eles ficam no inventário como monitorados, sem hash, e o navegador gera relatórios de violação para esses hosts.

Os scripts inline do snippetCopiar link da seção

O bootstrapper é inline e precisa continuar inline (veja Instalação do snippet). Escolha uma forma de autorizá-lo:

• Hash ('sha256-…'): autoriza exatamente aquele conteúdo. O hash muda quando o conteúdo do script muda: cada vez que você recola um snippet de versão nova e, se a loja tem regras inline, sempre que recola o snippet depois de mudar regras ou containers do Google Tag Manager, porque a configuração window.__PROTE_INLINE__ fica no início do mesmo script. Snippets antigos, com essa configuração numa tag separada, precisam de um segundo hash para ela.
• Nonce: se o seu servidor já gera um nonce por resposta, acrescente o atributo nonce às tags <script> do snippet ao colá-lo no template. O snippet do dashboard não traz nonce.
• 'unsafe-inline': funciona, mas libera qualquer script inline e enfraquece a política. Não recomendado em páginas de pagamento.

A forma mais segura de obter o hash é deixar o navegador calcular: publique a CSP sem o hash (de preferência em modo Content-Security-Policy-Report-Only), abra o checkout e veja a mensagem de violação no console. Ela informa o valor 'sha256-…' do script bloqueado. Para calcular localmente, use exatamente o conteúdo entre <script> e </script>, sem quebra de linha no final:

# bootstrapper.js = conteúdo entre <script> e </script>, copiado do snippet
printf '%s' "$(cat bootstrapper.js)" | openssl dgst -sha256 -binary | openssl base64

Exemplo de headerCopiar link da seção

Um exemplo para um checkout em minhaloja.com.br com Stripe. Adapte as outras origens à sua loja.

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'sha256-BOOTSTRAPPER_HASH' https://cdn.proteside.com https://js.stripe.com;
  connect-src 'self' https://app.proteside.com https://api.stripe.com;
  frame-src https://js.stripe.com;
  img-src 'self' data:;
  style-src 'self';
  report-uri https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e;
  report-to proteside
Reporting-Endpoints: proteside="https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e"

O header real vai em uma única linha; as quebras acima são só para leitura. Se o seu snippet é do formato antigo, com window.__PROTE_INLINE__ numa tag <script> separada, acrescente também o hash dessa tag.

Relatórios de violaçãoCopiar link da seção

O Proteside recebe relatórios de CSP no endereço abaixo. Ele não aparece em nenhuma tela do dashboard; use a sua chave do SDK no parâmetro key:

https://app.proteside.com/api/sdk/csp-report?key=pk_live_3f9c1a7b2e4d6f8a0c1e3b5d7f9a1c3e

• Aceita os dois formatos: report-uri e report-to (Reporting API).
• O total aparece em Saúde do SDK, no card Relatórios CSP (48 h).
• Uma violação de script-src ou connect-src para um host que não está no inventário de scripts da loja vira o alerta CSP_VIOLATION, com severidade baixa. Violações de outras diretivas só entram na contagem.
• Acima de 600 relatórios por minuto por chave, o excesso é descartado.

Para testar uma política nova sem quebrar o checkout, publique primeiro como Content-Security-Policy-Report-Only, acompanhe os relatórios e depois troque para Content-Security-Policy.

Headers de segurança monitoradosCopiar link da seção

Para apoiar a detecção de mudanças em headers, o SDK lê os headers de segurança da página de pagamento a cada carregamento e a cada Proteside.pageChanged():

Content-Security-Policy, Content-Security-Policy-Report-Only, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy, Cross-Origin-Resource-Policy, Access-Control-Allow-Origin e Set-Cookie (este só como "não legível no navegador").

O valor de cada header presente é enviado ao dashboard. Quando um valor muda, o dashboard cria o alerta HEADER_CHANGED. Os headers aparecem em Evidências PCI DSS, na aba Headers.

Subresource Integrity (SRI)Copiar link da seção

Não use o atributo integrity na tag do shield.js. Hoje o SRI não é viável por dois motivos:

1. A URL é mutável. O mesmo endereço recebe cada nova versão do SDK, então o hash mudaria a cada publicação e o navegador passaria a recusar o script.
2. A CDN não envia headers de CORS. Um <script integrity crossorigin="anonymous"> exige CORS, e o navegador bloquearia o carregamento.

Como controle preventivo, restrinja script-src a https://cdn.proteside.com e autorize o bootstrapper inline por hash ou nonce. O inventário do Proteside registra quais scripts da sua página usam integrity e nonce.

Relação com o PCI DSS 4.0Copiar link da seção

O Proteside gera evidências para esses requisitos em Evidências PCI DSS. A avaliação de conformidade continua sendo do seu avaliador (QSA) ou do seu questionário de autoavaliação. Veja Evidências PCI DSS.

Próximos passosCopiar link da seção

• Privacidade e LGPD
• Solução de problemas