O checkout Magento bloqueado por CSP pode transformar uma atualização simples em um problema grave de vendas. A loja continua abrindo normalmente, os produtos aparecem, o carrinho funciona, mas na hora de finalizar a compra o método de pagamento some, o botão não responde ou o checkout fica parcialmente quebrado.
Esse tipo de erro é perigoso porque nem sempre aparece uma mensagem clara para o cliente. Para quem compra, parece apenas que a loja está com problema. Para o lojista, o impacto pode ser direto: carrinhos abandonados, queda na conversão, chamados no atendimento e perda de faturamento.
A CSP, sigla para Content Security Policy, é uma política de segurança usada para reduzir riscos como XSS, skimmers de cartão, sequestro de sessão e scripts maliciosos executados no navegador. No Magento e Adobe Commerce, ela controla quais scripts, estilos, imagens, fontes e conexões externas podem ser carregados pela loja.
O que é CSP no Magento?
CSP significa Content Security Policy, ou Política de Segurança de Conteúdo. Na prática, é uma camada de proteção que informa ao navegador quais recursos externos podem ser executados em uma página.
No Magento, essa proteção é especialmente importante no checkout, porque essa área lida com dados pessoais, métodos de pagamento, endereço, frete e finalização do pedido.
O problema é que a mesma proteção que aumenta a segurança também pode bloquear scripts legítimos quando eles não estão configurados corretamente.
Isso pode acontecer com:
✅ scripts inline adicionados no tema;
✅ tags personalizadas no Google Tag Manager;
✅ módulos de pagamento antigos;
✅ scripts de antifraude;
✅ pixels de rastreamento;
✅ ferramentas de chat, heatmap ou remarketing;
✅ customizações adicionadas diretamente no header ou footer;
✅ extensões que não foram adaptadas para versões mais novas do Magento.
Quando isso acontece, o navegador pode impedir a execução do script e o checkout deixa de funcionar corretamente.
Por que o checkout Magento pode ser bloqueado por CSP?
O checkout Magento bloqueado por CSP acontece quando algum script necessário para carregar pagamento, validação, antifraude ou finalização do pedido não está autorizado pela política de segurança da loja.
A partir do Adobe Commerce e Magento Open Source 2.4.7, a configuração padrão da CSP nas páginas de pagamento passou a funcionar em modo restrict, enquanto as outras páginas continuam em modo report-only por padrão. Antes da versão 2.4.7, a CSP usava modo report-only em todas as páginas.
Na prática, isso significa que um script que antes apenas gerava aviso pode passar a ser bloqueado no checkout após uma atualização.
O erro costuma aparecer no console do navegador com mensagens parecidas com:
⚠️ “Refused to execute inline script because it violates the following Content Security Policy directive”
⚠️ “Refused to execute a script because its hash, its nonce, or unsafe-inline does not appear in the script-src directive”
⚠️ “Refused to load the script because it violates the Content Security Policy directive”
Para o cliente, esse erro técnico não aparece. O que ele vê é um checkout travado, incompleto ou sem método de pagamento.
Sinais de que o checkout Magento está com problema de CSP
Nem toda falha no checkout é causada por CSP, mas alguns sinais indicam que essa deve ser uma das primeiras hipóteses investigadas.
🔎 A loja abre normalmente, mas o problema aparece apenas no checkout.
🔎 O carrinho funciona, mas a etapa de pagamento não carrega.
🔎 O método de pagamento some da tela.
🔎 O botão “Finalizar pedido” não responde.
🔎 O checkout fica em loading infinito.
🔎 Algumas áreas do checkout ficam em branco.
🔎 O erro aparece depois de uma atualização do Magento.
🔎 O problema começou após instalar ou atualizar módulo de pagamento.
🔎 O console do navegador mostra mensagens com Content Security Policy, script-src, unsafe-inline, nonce ou hash.
Esse tipo de falha pode ser difícil de perceber em testes superficiais, porque a home, categorias, produtos e carrinho podem continuar funcionando normalmente.
Por que isso afeta tanto os pagamentos?
O checkout é uma das áreas mais sensíveis do Magento. Ele depende de vários scripts trabalhando juntos para validar dados, carregar métodos de pagamento, calcular informações e enviar o pedido.
Quando um desses scripts é bloqueado pela CSP, o fluxo pode quebrar.
💳 O formulário de cartão pode não aparecer.
💳 O Pix pode não carregar corretamente.
💳 O boleto pode não ser gerado.
💳 A autenticação 3DS pode falhar.
💳 O antifraude pode não retornar resposta.
💳 O botão de finalizar compra pode não ser habilitado.
💳 O pedido pode não ser enviado ao gateway.
💳 O cliente pode abandonar a compra sem avisar.
O risco é maior porque a loja nem sempre sai do ar. Ela continua aparentemente funcionando, mas perde vendas justamente na etapa mais importante: o pagamento.
Google Tag Manager também pode causar bloqueio no checkout
Muitas lojas Magento usam Google Tag Manager para carregar pixels, eventos, scripts de marketing, remarketing, ferramentas externas e códigos personalizados.
O problema é que tags do tipo Custom HTML podem inserir JavaScript inline na página. Em páginas de checkout com CSP restrita, esse tipo de script pode ser bloqueado se não estiver autorizado corretamente.
A própria Adobe cita problemas envolvendo JavaScript customizado adicionado via Admin e Google Tag Manager em páginas de checkout quando o modo restrito da CSP está habilitado.
Isso não significa que o Google Tag Manager não possa ser usado no Magento. Significa que ele precisa ser configurado com cuidado, principalmente em páginas de pagamento.
Quanto mais scripts de terceiros são carregados no checkout, maior o risco de conflito, bloqueio ou impacto na segurança.
Scripts no header e footer podem quebrar o checkout
Outro ponto comum em lojas Magento antigas é o uso de scripts adicionados diretamente no header ou footer pelo painel administrativo, pelo tema ou por módulos customizados.
Esses códigos podem incluir:
🧩 scripts de chat online;
🧩 pixels de redes sociais;
🧩 códigos de remarketing;
🧩 ferramentas de análise;
🧩 scripts de avaliação;
🧩 mapas de calor;
🧩 pop-ups promocionais;
🧩 integrações comerciais;
🧩 códigos antigos adicionados por agências anteriores.
Em versões antigas, esses scripts podiam funcionar sem grandes restrições. Mas com a CSP mais rígida nas páginas de pagamento, scripts inline adicionados dessa forma podem ser bloqueados.
O ideal é revisar quais scripts realmente precisam aparecer no checkout. Nem todo código de marketing precisa carregar na página de pagamento.
Como identificar se o problema é CSP
A primeira análise deve ser feita no navegador, usando o console de desenvolvedor.
Para isso, é preciso acessar o checkout, simular uma compra e observar se aparecem erros relacionados à política de segurança.
Procure mensagens com termos como:
🔎 Content Security Policy;
🔎 CSP;
🔎 script-src;
🔎 unsafe-inline;
🔎 nonce;
🔎 hash;
🔎 Refused to execute inline script;
🔎 Refused to load the script.
Depois disso, compare o comportamento entre as páginas da loja.
🔎 O script funciona na home, mas falha no checkout?
🔎 O erro aparece apenas na etapa de pagamento?
🔎 O problema começou após atualização?
🔎 Um novo módulo de pagamento foi instalado?
🔎 Alguma tag nova foi publicada no GTM?
🔎 Algum código foi inserido no header ou footer?
Se a resposta for sim para uma ou mais dessas perguntas, existe grande chance de o checkout estar sendo afetado por CSP.
O que revisar antes de alterar a CSP
Antes de liberar qualquer script, é importante entender exatamente o que está sendo bloqueado.
Não é recomendado simplesmente afrouxar a política de segurança para fazer o checkout voltar rapidamente. Isso pode resolver o sintoma, mas criar uma brecha maior.
Antes de alterar a CSP, revise:
🔎 qual script está sendo bloqueado;
🔎 de onde esse script vem;
🔎 se o domínio é confiável;
🔎 se o script pertence a um módulo legítimo;
🔎 se ele é realmente necessário no checkout;
🔎 se foi adicionado pelo tema, módulo, Admin ou GTM;
🔎 se existe versão atualizada da extensão;
🔎 se o gateway de pagamento é compatível com a versão atual do Magento;
🔎 se há customização antiga interferindo no fluxo de compra.
Esse cuidado evita transformar uma correção rápida em um problema de segurança.
Como corrigir checkout Magento bloqueado por CSP
A correção depende da origem do script bloqueado. Em muitos casos, será necessário ajustar o módulo, o tema ou a forma como o JavaScript foi inserido.
A documentação da Adobe recomenda alternativas como uso de SecureHtmlRenderer, CSPNonceProvider e ajustes via csp_whitelist.xml, dependendo do tipo de implementação e do script bloqueado.
Na prática, o caminho correto costuma ser:
🛠️ identificar o script bloqueado no console;
🛠️ confirmar se o script é legítimo;
🛠️ verificar se ele realmente precisa rodar no checkout;
🛠️ atualizar o módulo responsável, se houver versão compatível;
🛠️ ajustar a implementação no tema ou módulo;
🛠️ evitar liberação genérica de scripts inline;
🛠️ usar nonce, hash ou whitelist quando fizer sentido técnico;
🛠️ limpar cache do Magento;
🛠️ limpar cache do navegador/CDN, se necessário;
🛠️ testar uma compra completa;
🛠️ validar todos os métodos de pagamento ativos.
Em lojas com múltiplos gateways, o teste precisa ser feito em cada forma de pagamento. Não basta testar apenas boleto ou apenas cartão.
Por que não liberar tudo com unsafe-inline?
Uma reação comum é tentar resolver o erro liberando unsafe-inline. Isso pode até fazer alguns scripts voltarem a funcionar, mas enfraquece a proteção da loja.
O objetivo da CSP é justamente impedir que scripts inline não autorizados sejam executados no navegador.
Ao liberar tudo de forma ampla, a loja pode ficar mais exposta a ataques, principalmente no checkout.
Em lojas Magento, esse risco é ainda mais sério porque ataques com skimmers podem tentar capturar dados digitados pelo cliente durante a compra. A Adobe descreve a CSP como uma proteção contra ameaças como XSS e card skimmers.
Por isso, o ideal é liberar apenas o que for necessário, confiável e tecnicamente validado.
O impacto comercial de um checkout bloqueado
Um checkout Magento bloqueado por CSP não é apenas um erro técnico. É um problema comercial.
Quando o cliente não consegue pagar, ele dificilmente abre chamado explicando o erro. Na maioria das vezes, ele simplesmente abandona a compra e procura outro fornecedor.
Esse tipo de falha pode gerar:
🚨 queda na taxa de conversão;
🚨 aumento de carrinhos abandonados;
🚨 perda de vendas em campanhas pagas;
🚨 reclamações no atendimento;
🚨 dificuldade para identificar a causa real;
🚨 prejuízo em datas promocionais;
🚨 perda de confiança na loja;
🚨 desperdício de investimento em mídia;
🚨 falsa sensação de que a loja está funcionando normalmente.
O impacto pode ser ainda maior quando o problema aparece depois de uma atualização feita sem testes completos.
Como evitar esse problema em atualizações Magento
Antes de atualizar Magento ou Adobe Commerce, o checkout precisa entrar no checklist principal de testes.
Não basta validar se a home abre, se os produtos aparecem ou se o Admin está funcionando. É necessário testar o fluxo completo de compra.
Antes de colocar uma atualização em produção, revise:
✅ carregamento completo do checkout;
✅ cálculo de frete;
✅ aplicação de cupom;
✅ login de cliente;
✅ compra como visitante;
✅ criação de conta durante o checkout;
✅ pagamento com cartão;
✅ pagamento via Pix;
✅ pagamento via boleto;
✅ carteiras digitais, se existirem;
✅ retorno do gateway;
✅ criação do pedido no Admin;
✅ envio de e-mails transacionais;
✅ logs do Magento;
✅ console do navegador;
✅ erros relacionados a CSP;
✅ comportamento em desktop e mobile.
Também é importante testar scripts externos, tags de marketing e módulos de terceiros. Uma loja pode não apresentar erro no backend, mas ainda assim ter bloqueio no navegador.
Checklist rápido para revisar CSP no checkout Magento
Use este checklist quando houver suspeita de bloqueio por CSP no checkout:
✅ Verifique se o erro aparece apenas no checkout ou pagamento.
✅ Abra o console do navegador e procure mensagens de CSP.
✅ Revise scripts adicionados via Google Tag Manager.
✅ Confira códigos inseridos no header e footer pelo Admin.
✅ Verifique se o módulo de pagamento está atualizado.
✅ Confirme se o gateway é compatível com a versão atual do Magento.
✅ Teste todos os métodos de pagamento ativos.
✅ Evite liberar unsafe-inline de forma genérica.
✅ Use nonce, hash ou whitelist quando for tecnicamente necessário.
✅ Limpe cache após os ajustes.
✅ Faça uma compra completa em ambiente de teste.
✅ Monitore carrinhos abandonados após atualizações.
✅ Compare a conversão antes e depois da mudança.
Erros comuns ao tentar corrigir CSP no Magento
Muitas correções de CSP são feitas de forma apressada, principalmente quando o checkout já está impactando vendas.
Os erros mais comuns são:
❌ liberar scripts demais sem identificar a origem do problema;
❌ adicionar domínios externos sem verificar se são confiáveis;
❌ usar unsafe-inline como solução definitiva;
❌ mexer na CSP sem testar todos os métodos de pagamento;
❌ ignorar scripts adicionados via Google Tag Manager;
❌ esquecer códigos antigos no header e footer;
❌ atualizar Magento sem atualizar módulos de pagamento;
❌ testar apenas a home e o carrinho;
❌ não verificar o console do navegador;
❌ não acompanhar conversão após a correção.
O ideal é tratar a causa real do bloqueio, não apenas esconder o erro.
CSP pode afetar também o pedido criado pelo Admin?
Sim. Além do checkout da loja, a Adobe também documenta problemas em páginas de criação de pedido pelo Admin quando o modo restrito da CSP está habilitado no Adobe Commerce 2.4.7.
Isso é importante para lojas que recebem pedidos por telefone, WhatsApp, equipe comercial ou televendas e criam pedidos manualmente no painel administrativo.
Nesses casos, a falha pode afetar:
🧾 criação manual de pedidos;
🧾 seleção de método de pagamento no Admin;
🧾 scripts de pagamento carregados no painel;
🧾 módulos customizados usados pela equipe comercial;
🧾 operações internas de venda.
Por isso, o teste pós-atualização não deve ficar restrito ao checkout da loja. O fluxo de criação de pedido no Admin também precisa ser validado.
Quando o problema merece análise técnica
O erro de CSP pode parecer simples, mas nem sempre é seguro resolver apenas liberando scripts.
O problema merece uma análise técnica mais cuidadosa quando:
⚠️ o checkout parou logo após atualização do Magento;
⚠️ o problema afeta cartão, Pix, boleto ou gateway específico;
⚠️ o erro aparece apenas para alguns clientes;
⚠️ o checkout funciona em um navegador, mas falha em outro;
⚠️ existem muitos scripts via Google Tag Manager;
⚠️ a loja usa tema antigo ou muito customizado;
⚠️ há módulos de pagamento desatualizados;
⚠️ o console mostra múltiplos erros de CSP;
⚠️ a loja já sofreu invasão ou suspeita de skimmer;
⚠️ a conversão caiu sem explicação clara.
Em lojas Magento 1, Magento 2 ou Adobe Commerce com customizações antigas, a revisão precisa ser ainda mais cuidadosa. Muitos scripts podem ter sido adicionados antes das exigências atuais de segurança e compatibilidade.
Resumo prático para lojistas
O checkout Magento bloqueado por CSP geralmente acontece quando a política de segurança impede a execução de scripts necessários para pagamento ou finalização de compra.
Na prática, o lojista precisa ficar atento quando:
✅ o pagamento some da tela;
✅ o botão de finalizar pedido não funciona;
✅ o checkout fica carregando sem concluir;
✅ o erro aparece após atualização;
✅ o gateway foi atualizado ou trocado;
✅ novas tags foram publicadas no Google Tag Manager;
✅ o console mostra mensagens de Content Security Policy.
A correção deve ser feita com cuidado. A CSP existe para proteger a loja, especialmente contra ataques envolvendo scripts maliciosos e roubo de dados no checkout.
Por isso, o melhor caminho é identificar o script bloqueado, validar sua origem, corrigir a implementação e testar o fluxo completo de compra antes de considerar o problema resolvido.
