Segurança e Hardening do Magento 2: Guia Completo Anti-Magecart

Patches de segurança e boletins APSB: a base de tudo

A esmagadora maioria das lojas Magento comprometidas é invadida por uma única razão: não aplicou um patch que já existia. Manter a versão atualizada é a medida de segurança com melhor custo-benefício que existe. A Adobe publica boletins de segurança no formato APSB (ex.: APSB25-08) descrevendo as CVEs corrigidas, versões afetadas e o nível de severidade.

A nova cadência mensal (a partir de 2026)

Houve uma mudança importante: a partir de 6 de janeiro de 2026, a Adobe abandonou a cadência trimestral e passou a liberar patches de segurança isolados, com periodicidade mensal, para todas as linhas suportadas. Cada security patch contém apenas correções de segurança e é versionado com o sufixo -pN (por exemplo, 2.4.7-p3), começando em 1. Esses patches de segurança saem ao longo de todo o ano — inclusive em maio, com a diferença de que, em maio, o full patch release anual (a linha maior, como 2.4.9) também agrega os fixes de segurança acumulados, somados às correções de qualidade. Em outras palavras, maio não fica sem cobertura de segurança; ele entrega tudo em um único pacote. As linhas LTS 2.4.x contam com 3 anos de suporte.

Versões de plataforma também importam

Hardening não é só patch de código: rodar componentes de plataforma fora de suporte é dívida de segurança. Como referência, as linhas 2.4.8 e 2.4.9 suportam OpenSearch 2.x e 3.x (com a 3.x recomendada), e o cache/sessões pode usar Redis ou, nas versões recentes, o Valkey — o fork open source do Redis adotado nativamente a partir do 2.4.8. Manter PHP, banco e mecanismo de busca em versões suportadas garante que você continue recebendo correções.

Por que aplicar no mesmo dia

Quando a Adobe libera um boletim, ela também publica os detalhes da vulnerabilidade. Grupos como Peschanki e Laski fazem engenharia reversa do patch em horas e varrem a internet atrás de lojas vulneráveis. Veja o caso do APSB25-08 (11 de fevereiro de 2025), que corrigiu as versões 2.4.8-beta1, 2.4.7-p3, 2.4.6-p8, 2.4.5-p10, 2.4.4-p11 e anteriores. Para o CVE-2025-24434, a Adobe disponibilizou um patch isolado, permitindo aplicação com menos risco de regressão antes do upgrade completo.

Successful exploitation of these vulnerabilities could lead to arbitrary code execution, security feature bypass, and privilege escalation.

Fonte: Adobe Experience League (KB ka-27149)

Recomendação prática: assine o RSS dos boletins, mantenha um ambiente de staging para validar o patch e tenha uma janela de manutenção pré-acordada. Lojas em Magento 1 precisam de atenção redobrada — o suporte encerrou em 30 de junho de 2020, sem qualquer patch de segurança desde então. Se você ainda roda Magento 1, está navegando sem coletes salva-vidas; planejar a migração de Magento 1 para Magento 2 deixa de ser projeto de roadmap e vira prioridade absoluta de segurança.

2FA obrigatório no admin desde o Magento 2.4

O painel admin é o alvo número um de ataques de força bruta e credential stuffing. Por isso, desde o Magento/Adobe Commerce 2.4.0, a autenticação de dois fatores passou a ser habilitada por padrão e obrigatória no painel Admin — tanto na interface quanto na Web API — através do módulo Magento_TwoFactorAuth. A proteção vale independentemente de IP ou rede: no primeiro login, o administrador é obrigado a configurar o 2FA.

Provedores suportados

• Google Authenticator: TOTP gratuito, o mais comum no Brasil.
• Duo Security: push notification, ideal para times.
• Authy: TOTP com backup em nuvem.
• U2F: chaves físicas de segurança (YubiKey e similares), o nível mais forte.

Não desabilite — a não ser que tenha um motivo muito forte

Tecnicamente é possível desligar com php bin/magento module:disable Magento_TwoFactorAuth, mas a Adobe — e eu — recomendamos fortemente não fazer isso. Já vi lojas desabilitarem o 2FA "para facilitar" e serem invadidas semanas depois. Se um colaborador perde o acesso ao app autenticador, a forma correta de resetar é via linha de comando, não desligando o módulo inteiro:

php bin/magento security:tfa:reset <usuario> google

O comando força o reonboarding daquele usuário específico no próximo login, sem afetar os demais administradores nem reduzir a postura de segurança da loja.

Segundo a documentação de administração da Adobe, o 2FA é exigido para confirmar a identidade do usuário no Admin por meio de uma senha de uso único gerada por um app ou dispositivo, e o administrador é solicitado a configurá-lo já no primeiro acesso ao painel. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

Combine o 2FA com reCAPTCHA no formulário de login e com a política de bloqueio por tentativas (detalhada na próxima seção) e você fecha quase todos os vetores de ataque direto ao admin.

Magecart e CosmicSting: como os skimmers de cartão funcionam

Magecart é o nome genérico para grupos que praticam web skimming: injetam JavaScript malicioso na página de checkout para interceptar os dados do cartão no momento em que o cliente digita, enviando-os a servidores de coleta. O ataque é invisível tanto para o cliente quanto para o lojista — a transação ocorre normalmente, mas os dados são copiados em paralelo.

A linha do tempo do problema

O primeiro ataque em massa ocorreu em 2015, após a falha SUPEE-5344 ("Shoplift"). Já em dezembro de 2015 a Sansec identificava mais de 3.000 lojas Magento comprometidas. Até 2022, o número acumulado passou de 70.000 lojas com skimmer (mais de 100.000 contando supply chain). A Sansec adiciona cerca de 30 assinaturas de malware por dia ao eComscan — a indústria criminosa é industrializada.

CosmicSting: o pior bug em dois anos

O CVE-2024-34102 (CosmicSting) é uma vulnerabilidade XXE não autenticada com CVSS 9.8, corrigida em 11 de junho de 2024. O ataque rouba a crypt key de app/etc/env.php e gera um JWT que dá acesso irrestrito à API do Magento, permitindo injetar JS malicioso em blocos CMS.

CosmicSting (aka CVE-2024-34102) is the worst bug to hit Magento and Adobe Commerce stores in two years. [...] stores are getting hacked at a rate of 5 to 30 per hour.

Fonte: Sansec

A Sansec também registrou, no artigo de 18 de junho de 2024, que 75% das lojas ainda não haviam aplicado o patch — daí a janela de exploração em massa. Lição crítica: aplicar o patch não basta. Se a crypt key já foi exfiltrada, o invasor continua gerando JWTs válidos. A mitigação completa exige invalidar e rotacionar a crypt key de app/etc/env.php após aplicar o patch:

php bin/magento config:set --lock-config some/dummy 1
# Substitua a chave 'crypt/key' em app/etc/env.php por uma nova de 32 bytes
php bin/magento setup:upgrade && php bin/magento cache:flush

Skimmers modernos também usam técnicas de evasão sofisticadas — WebRTC DataChannels, abuso de Google Translate/YouTube/Analytics e até o uso do Stripe como servidor de comando.

Hardening do admin: URL customizada, ACL, senhas e bloqueio

Além do 2FA, há um conjunto de configurações de hardening do admin que a Adobe documenta como best practices e que eu aplico em todo projeto. Elas reduzem drasticamente a superfície de ataque ao painel.

Configurações essenciais de segurança do admin

ACL e o princípio do menor privilégio

Em System > Permissions > User Roles, aplique o princípio do menor privilégio: cada usuário recebe apenas as permissões de que precisa. Um detalhe que muita gente esquece e é vetor de auto-escalada: ao restringir um role, desabilite o acesso à própria ferramenta Permissions, senão o usuário pode editar o próprio role e se promover a administrador. Use o escopo Custom para limitar o acesso a websites/stores específicos — fundamental em operações multiloja.

Segundo a documentação da Adobe sobre user roles, ao restringir o acesso de um determinado role é preciso desabilitar o acesso à ferramenta Permissions; caso contrário, os usuários conseguem modificar as próprias permissões. A mesma página explica que, no escopo Custom, seleciona-se o website e a store onde aquele role pode atuar. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

reCAPTCHA e restrição por IP

Habilite o reCAPTCHA no formulário de login do admin para frear força bruta automatizada. Em ambientes onde a equipe acessa de IPs fixos, restrinja o caminho do admin no nível do servidor web (Nginx/Apache) ou do firewall a uma allowlist de IPs. Combinada com a URL customizada e o secret key, essa camada torna o admin praticamente invisível para varreduras automatizadas.

Permissões de arquivos, usuário do servidor e bloqueio em pub/media

Permissões mal configuradas são um convite para webshells. Skimmers frequentemente fazem upload de scripts PHP maliciosos em diretórios graváveis para manter persistência. O objetivo do hardening de arquivos é garantir que o web server escreva apenas onde precisa — e que nada executável rode onde não deveria.

Diretórios que o web server precisa escrever

• var: cache, sessões, logs.
• generated: classes geradas.
• vendor: dependências (instalação por Composer ou archive).
• pub/static: assets compilados.
• app/etc: arquivos de configuração.

O diretório pub/media (uploads e imagens de produto) também é gravável na prática, mas merece tratamento especial de hardening — veja o bloqueio de execução de PHP mais abaixo.

umask e modelos de hospedagem

O umask padrão (002) gera permissões 775 para diretórios e 664 para arquivos. A Adobe sugere usar umask 022 (resultando em 755 / 644) através de um arquivo magento_umask na raiz da aplicação — apenas em hospedagem de um usuário/compartilhada:

echo 022 > magento_umask

Em servidores privados com modelo de dois usuários (ex.: usuário de deploy + usuário do web server), ambos devem pertencer ao mesmo grupo. O procedimento típico:

usermod -a -G <grupo_webserver> <usuario_deploy>
chmod g+w <diretorios_gravaveis>
chmod g+ws <diretorios>
chmod u+x bin/magento

Segundo o guia de instalação da Adobe, os diretórios que precisam de permissão de escrita são vendor, app/etc, pub/static, var e generated (além de outros recursos estáticos). A própria documentação distingue o modelo de um único usuário (hospedagem compartilhada) do modelo de dois usuários, em que o dono dos arquivos e o usuário do web server compartilham um grupo. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

Bloquear execução de PHP em pub/media

Esta é uma das medidas de hardening mais importantes e mais negligenciadas: impedir a execução de PHP e outros scripts em pub/media. Como esse diretório recebe uploads, é o local preferido de invasores para plantar webshells. No Nginx, negue a execução de .php sob /media:

location ~* ^/media/.*\.(php|php5|phtml|pl|py|cgi)$ {
    deny all;
}

No Apache, use um .htaccess que remova handlers PHP e force Content-Type estático. Assim, mesmo que um arquivo malicioso seja enviado, ele nunca será executado pelo interpretador.

HTTPS, HSTS, secure base URL e cookies seguros

Sem HTTPS de ponta a ponta, todo o esforço de segurança vai por água abaixo — dados trafegam em texto claro e cookies de sessão podem ser interceptados. A Adobe recomenda transmitir todas as páginas da loja de produção via HTTPS, não apenas o checkout.

Configuração em Stores > Configuration > General > Web

1. Defina a Secure Base URL como https://seudominio/.
2. Ative Use Secure URLs on Storefront (web/secure/use_in_frontend) como Yes.
3. Ative Use Secure URLs in Admin (web/secure/use_in_adminhtml) como Yes.

Com ambos em Yes, surgem duas opções adicionais que você deve ativar: Enable HTTP Strict Transport Security (HSTS) e Upgrade Insecure Requests. O HSTS instrui o navegador a sempre usar HTTPS para o domínio, eliminando a janela de downgrade para HTTP. O Upgrade Insecure Requests reescreve referências HTTP remanescentes para HTTPS, evitando avisos de conteúdo misto. A consistência de protocolo e de URLs base também evita redirecionamentos desnecessários e conteúdo duplicado — um ponto que tratamos a fundo no guia de SEO Técnico para Magento 2.

Cookies HttpOnly e Secure

A flag HttpOnly impede que JavaScript leia o cookie de sessão — uma defesa direta contra roubo de sessão via XSS. Ela é controlada por web/cookie/cookie_httponly. Combinada com a flag Secure (cookie só transita por HTTPS), você protege a sessão tanto contra interceptação de rede quanto contra scripts maliciosos.

Segundo a documentação da Adobe, é fortemente recomendado transmitir todas as páginas de um site de produção — incluindo páginas de conteúdo e de produto — usando um protocolo seguro. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

Você pode aplicar essas configurações por linha de comando, o que é ideal para versionar em pipelines de deploy:

php bin/magento config:set web/secure/use_in_frontend 1
php bin/magento config:set web/secure/use_in_adminhtml 1
php bin/magento config:set web/cookie/cookie_httponly 1

Depois de alterar URLs base, limpe o cache de configuração com php bin/magento cache:flush para que as mudanças sejam efetivadas.

CSP: Content Security Policy contra injeção de scripts

Se o 2FA e os patches protegem a entrada, o CSP (Content Security Policy) é sua última linha de defesa contra Magecart: ele instrui o navegador a só executar scripts de origens autorizadas. A Sansec é enfática quanto à eficácia dessa camada contra skimming.

Histórico e modos no Magento

O suporte chegou na versão 2.3.5 via módulo Magento_Csp. A partir do 2.4.7, o CSP fica em restrict-mode por padrão para páginas de pagamento (storefront e admin) e em report-only nas demais páginas. Antes do 2.4.7, era report-only em todas.

Como implementar sem quebrar a loja

Comece em report-only, monitore os relatórios de violação por alguns dias e cadastre as origens legítimas. Recursos confiáveis são adicionados via csp_whitelist.xml no diretório etc/ de um módulo:

<policy id="script-src">
  <values>
    <value id="example" type="host">https://example.com</value>
  </values>
</policy>

Os modos são alternados em etc/config.xml via default/csp/mode/admin/report_only e default/csp/mode/storefront/report_only — onde 0 = restrict e 1 = report-only. Quando estiver confiante de que a whitelist está completa, mude para restrict-mode.

The majority of all digital skimming attacks to date would have been stopped by a proper CSP implementation.

Fonte: Sansec

Complemente o CSP com SRI (Subresource Integrity), que adiciona ao HTML um hash verificando que o script externo não foi adulterado — se um CDN comprometido alterar o arquivo, o navegador recusa carregá-lo. A própria Sansec relaciona CSP e SRI aos requisitos PCI DSS 6.4.3 e 11.3.1. Vale a distinção: a numeração específica do PCI DSS 4.0.1 que cito na seção de PCI (6.4.3 e 11.6.1) vem do PCI Security Standards Council, não dessa página da Sansec. Como o CSP roda no navegador, ele convive bem com cache de borda e não pesa no tempo de render — o que conversa diretamente com Performance e Core Web Vitals, já que scripts de terceiros são a maior causa tanto de risco de skimming quanto de degradação de métricas.

WAF Fastly, rate limiting e proteção de borda

Um WAF (Web Application Firewall) filtra tráfego malicioso antes que ele chegue à aplicação. No Adobe Commerce on cloud infrastructure, o WAF é powered by Fastly e está disponível apenas em ambientes de produção.

O que o WAF Fastly detecta e bloqueia

Ele detecta, registra e bloqueia injection, XSS, exfiltração de dados, violações de protocolo HTTP e ameaças do OWASP Top Ten, com base em ModSecurity Rules da Trustwave SpiderLabs combinadas a regras específicas do Adobe Commerce, atualizadas conforme novas CVEs surgem. A latência estimada é baixa: de 1,5 ms a 20 ms por requisição não-cacheada.

Segundo a documentação da Adobe, o serviço de WAF do Adobe Commerce on cloud infrastructure é powered by Fastly, está disponível apenas em ambientes de produção e detecta, registra e bloqueia tráfego malicioso usando regras ModSecurity da Trustwave SpiderLabs e cobertura do OWASP Top Ten, com latência estimada de 1,5 ms a 20 ms por requisição não-cacheada. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

Rate limiting: não é o WAF padrão

Um ponto que confunde muita gente: rate limiting não é recurso embutido do WAF padrão. Para limitar requisições, você usa o Fastly rate limiting ou o rate limiting de Web API, introduzido no 2.4.7, desabilitado por padrão e com backend em Redis (Redis 7.2 no 2.4.7) ou, nas versões recentes, em Valkey. Os caminhos de configuração:

Você ativa via bin/magento config:set sales/backpressure/enabled 1. Vale lembrar que a REST API já limita listas a 20 entidades e paginação a 300 itens por padrão, o que ajuda a conter scraping.

Não confunda ferramentas de borda com profiling

No Adobe Commerce Cloud, o Blackfire é disponibilizado para profiling de performance, mas não é uma ferramenta de segurança nem substitui o WAF — são escopos diferentes. Para lojas fora da cloud da Adobe, recomendo um WAF externo (Cloudflare, AWS WAF) com regras OWASP equivalentes; não deixe a aplicação exposta sem essa camada de borda. Quem opera integrações com ERP e NF-e deve garantir que as allowlists do WAF e do rate limiting contemplem os IPs e endpoints desses sistemas, evitando bloquear chamadas legítimas de retaguarda.

Security Scan Tool, vetting de extensões e monitoramento

Hardening sem monitoramento é incompleto: você precisa saber se algo deu errado. A Adobe oferece o Security Scan Tool, gratuito, disponível no dashboard da sua conta Commerce/Magento e que funciona em qualquer versão de Adobe Commerce.

O que o Security Scan Tool faz

Ele executa mais de 21.000 testes de segurança, identificando malware, injeções de skimming, patches de segurança desatualizados, extensões vulneráveis e misconfigurations. A frequência é configurável: semanal (padrão sábado meia-noite UTC), diária (padrão meia-noite UTC) ou on-demand, com notificação por e-mail. O setup exige verificação de propriedade do domínio via código de confirmação na storefront.

Segundo a documentação da Adobe, o Security Scan Tool está disponível gratuitamente no dashboard da conta Commerce/Magento e executa mais de 21.000 testes de segurança para ajudar a identificar potencial malware, com agendamento semanal, diário ou on-demand. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

Cadeia de suprimentos: vetting de extensões

Boa parte dos comprometimentos modernos vem de extensões de terceiros maliciosas ou desatualizadas. A Adobe Commerce Marketplace executa malware scan em todo código, mídia e documento submetido, usando antivírus de propósito geral com base atualizada + Yara com regras específicas do Commerce; submissões reprovadas são rejeitadas sem validação adicional. Minhas regras de ouro:

• Origem confiável: obtenha extensões apenas via Marketplace oficial ou integrador de soluções.
• Revisão de código: revise o código da extensão antes da integração, especialmente uploads e chamadas externas.
• Inventário: mantenha uma lista de extensões com versão e responsável por atualizar.
• Credenciais de integração: rotacione tokens e chaves de conectores de retaguarda e jamais os exponha no front; integrações como as descritas no guia de ERP e NF-e ampliam a superfície de ataque se mal isoladas.

eComscan e monitoramento de integridade

Para detecção de malware mais agressiva, o eComscan da Sansec examina arquivos, bancos de dados e componentes de terceiros em busca de malware, vulnerabilidades e contas não autorizadas. A equipe Sansec analisa 200 a 300 hacks de e-commerce por semana e afirma que 47% da sua threat intel não é descoberta por outras firmas. Complemente com monitoramento de integridade de arquivos (FIM): qualquer alteração inesperada em arquivos PHP ou JS de checkout deve gerar alerta imediato — é assim que você pega um skimmer nas primeiras horas, e não depois de meses.

Backups, logging, resposta a incidentes e PCI DSS

Mesmo com todas as camadas anteriores, você precisa estar preparado para o pior. Backups confiáveis, logs auditáveis e um plano de resposta a incidentes definem se uma invasão será um susto ou uma catástrofe.

Backups e logging na cloud da Adobe

No Adobe Commerce on cloud infrastructure (Pro), cada cliente fica em ambiente isolado (VPC). Os backups são feitos a cada hora nas últimas 24 horas e depois seguem o modelo de AWS EBS Snapshots. Todos os volumes EBS são criptografados com AES-256 (dados em repouso) e senhas de clientes são armazenadas como hashes. O logging usa AWS CloudTrail, com CrowdStrike Falcon EDR em todos os endpoints e pentest periódico pelo Managed Services.

Segundo a documentação de segurança da Adobe, no plano Pro os backups são feitos a cada hora durante as últimas 24 horas de operação e, após esse período, retidos via AWS EBS Snapshot; todos os volumes EBS são criptografados com AES-256, as senhas de clientes ficam como hashes, as atividades AWS são registradas no CloudTrail e o CrowdStrike Falcon EDR é instalado em todos os endpoints, dentro de uma VPC isolada. (Resumo da fonte, não citação literal.)

Fonte: Adobe Experience League

PCI DSS e o modelo de responsabilidade compartilhada

O Adobe Commerce é certificado como PCI DSS Level 1 Service Provider (Attestation of Compliance disponível sob solicitação). Mas atenção ao modelo de responsabilidade compartilhada: a Adobe mantém a certificação PCI da infraestrutura e serviços; o lojista responde pela conformidade do código customizado, processos internos e pela execução de ASV scans.

PCI DSS 4.0.1 e Magecart

Dois novos requisitos, obrigatórios desde 31 de março de 2025, atacam diretamente o Magecart (numeração conforme o PCI Security Standards Council):

Resposta a incidentes

Tenha um runbook pronto. Se detectar comprometimento: isole a loja, preserve logs, aplique patches, rotacione a crypt key e todas as credenciais, restaure de um backup limpo anterior à invasão, rode eComscan/Security Scan para confirmar a limpeza e só então reabra. Documente tudo para a investigação forense e para a notificação aos adquirentes, conforme exigido pelo PCI.