Segurança em lojas Magento 2: checklist prático para 2026

Uma loja Magento 2 não é insegura por padrão. O risco aparece quando a operação cresce, as integrações se acumulam e decisões técnicas ficam sem documentação. Nesse ponto, ataques automatizados, extensões vulneráveis e falhas de configuração passam a funcionar contra a loja.

Este checklist de segurança Magento 2 organiza as medidas por camada: atualizações, acesso ao admin, servidor, navegador do cliente, extensões, dados, monitoramento, integrações e recuperação. Use-o como roteiro de auditoria com o seu time e com o seu parceiro de tecnologia, e anote um responsável e uma data para cada item.

Principais pontos

• Segurança em camadas: código, servidor, acessos, dados e integrações precisam de cuidado ao mesmo tempo, porque o ponto mais fraco decide o resultado.
• Patch aplicado não encerra o assunto: uma falha pode ser explorada antes de existir correção, então a loja também precisa de monitoramento.
• O admin é o alvo mais visado: usuários individuais, permissões mínimas e autenticação em dois fatores (2FA) vêm antes de qualquer ajuste fino.
• Extensões e integrações ampliam a superfície de ataque: cada módulo e cada token são uma porta que alguém precisa vigiar.
• Backup só vale depois de restaurado em teste, e o plano de incidente precisa existir antes do incidente.

Para quem este checklist é indicado

• Gestores técnicos de e-commerce Magento 2.
• Desenvolvedores responsáveis pela sustentação da loja.
• Times de infraestrutura e DevOps.
• Operações B2B e B2C que tratam dados sensíveis.
• Lojas que já sofreram um incidente ou querem evitar o primeiro.

Segurança Magento 2: checklist por camada

1. Atualizações e ciclo de patches

• A Adobe publica os patches de segurança do Magento e do Adobe Commerce todo mês, na segunda terça-feira. Quando uma falha crítica já está em exploração, a Adobe publica a correção fora desse calendário. Acompanhe os boletins de segurança da Adobe e defina quem os lê e em quanto tempo a equipe responde.
• Mantenha a loja em uma linha com suporte regular. Segundo a documentação da Adobe, o suporte regular da 2.4.6 terminou em 11 de agosto de 2026, o da 2.4.7 vai até 31 de maio de 2027, o da 2.4.8 até 31 de maio de 2028 e o da 2.4.9 até 31 de maio de 2029. Quem está em uma linha encerrada precisa de um plano de upgrade do Magento.
• Use o Composer para aplicar atualizações e patches. Evite alterar arquivos do núcleo ou de pacotes à mão.
• Valide cada patch em homologação, com cópia recente do banco, antes de levar à produção.
• Atualize também as extensões de terceiros, e não só o núcleo.

Um exemplo de por que o calendário não basta: em setembro de 2026, a Adobe publicou o boletim APSB26-146, fora do pacote mensal, para a CVE-2026-75650, uma falha crítica de execução de código sem autenticação que a própria Adobe informou estar sendo explorada. O pacote mensal saiu no dia seguinte, e a Adobe orientou aplicar o hotfix além do pacote mensal.

2. Controle dos usuários administrativos

• Não use contas compartilhadas. Crie um usuário para cada pessoa, com a função de menor permissão que resolva o trabalho dela.
• Mantenha a autenticação em dois fatores (2FA) ativa. No Magento 2.4, ela vem habilitada por padrão desde a versão 2.4.0, e a Adobe recomenda não desativar o módulo.
• Revogue na mesma hora o acesso de quem saiu da empresa ou de um fornecedor que deixou de atender a loja.
• Revise as permissões a cada mudança de equipe.
• Defina uma política de senhas. Por padrão, o Magento exige pelo menos sete caracteres com letras e números e bloqueia a reutilização das quatro últimas senhas. Em lojas com dados sensíveis, exija mais do que o mínimo.
• Treine a equipe para reconhecer phishing e para não compartilhar credenciais. O fator humano costuma ser o elo mais fraco.

3. Proteção do painel administrativo

• Troque a URL do admin por uma que não seja fácil de adivinhar. A Adobe recomenda evitar nomes óbvios, como “admin” e “backend”.
• Mantenha ativa a chave secreta nas URLs do admin, que vem habilitada por padrão.
• Restrinja o acesso ao admin por lista de IPs permitidos no servidor web ou no firewall, sempre que a operação permitir. Quando não permitir, considere uma camada extra de autenticação no servidor.
• Configure o bloqueio de conta após tentativas de login falhas. O padrão do Magento são seis tentativas.
• Defina o tempo máximo de sessão do admin e desative o compartilhamento de conta entre dispositivos.
• Ative o CAPTCHA no login do admin, que o Magento permite configurar.
• Acompanhe os registros de tentativas de login e de alterações administrativas.

4. Servidor, arquitetura e permissões

• Não hospede o Magento em ambiente compartilhado.
• Separe os componentes: servidor web, banco de dados e cache (Redis ou Valkey, Varnish). Cada um deve aceitar conexões apenas de quem precisa delas.
• Nunca exponha o banco de dados diretamente à internet.
• Use um firewall de aplicação web (WAF) na frente da loja para filtrar tentativas de injeção de SQL e de cross-site scripting (XSS).
• Coloque a loja em modo de produção (bin/magento deploy:mode:set production). A documentação da Adobe orienta remover a permissão de escrita dos diretórios de código em produção e restringir o acesso ao arquivo app/etc/env.php.
• Impeça a execução de scripts PHP nos diretórios de upload e de mídia.
• Rode o cron com o usuário correto do sistema e acompanhe falhas recorrentes.
• Remova do servidor softwares e serviços que ninguém usa mais, porque componentes esquecidos acumulam falhas sem receber correção.

5. HTTPS, certificados e política de segurança de conteúdo

• Use HTTPS em toda a loja, inclusive no admin, com certificado emitido por uma autoridade confiável e renovação automática. Um certificado vencido derruba a confiança do cliente e a conversão.
• Configure a Content Security Policy (CSP), que limita de onde a página pode carregar scripts. A partir do Magento 2.4.7, as páginas de pagamento da loja e do admin usam o modo restritivo por padrão, e as demais páginas ficam em modo de apenas relatório. Antes da 2.4.7, todas as páginas ficavam em modo de relatório.
• Depois de um upgrade, teste o checkout. A própria Adobe documenta que o modo restritivo pode bloquear scripts inline e deixar a página de pagamento em branco até que a lista de permissões seja ajustada. O arquivo csp_whitelist.xml e o gerador de nonce da versão 2.4.7 existem para esse ajuste.
• Configure no servidor os cabeçalhos X-Frame-Options e X-Content-Type-Options.
• Revise os scripts de terceiros (chat, pixels, recomendação): cada um é código de outra empresa executando na página de pagamento.

6. Extensões: menos é mais

• Instale só as extensões que a operação usa.
• Antes de instalar, verifique o histórico de atualizações, a compatibilidade com a versão da loja e a reputação do fornecedor.
• Remova os módulos sem uso. Um módulo abandonado deixa de receber correções e continua carregado.
• Nunca instale extensões direto em produção: valide em homologação primeiro.
• Revise o código customizado com a mesma régua das extensões de terceiros.

7. Banco de dados, chaves e dados sensíveis

• Use usuários de banco com permissões mínimas.
• Proteja a chave de criptografia do Magento. Ela fica na configuração do ambiente e cifra dados sensíveis no banco, como credenciais de integrações.
• Saiba rotacionar essa chave antes de precisar. A partir do Adobe Commerce 2.4.8, a troca é feita pela linha de comando (bin/magento encryption:key:change), com modo de manutenção ativo e cron desligado. A troca encerra as sessões de clientes e de administradores.
• Se a chave pode ter vazado, troque também as credenciais que ela protegia. A Adobe recomenda rotacionar a chave e as credenciais associadas como parte da resposta a uma falha explorada.
• Use um meio de pagamento com tokenização, para que a loja não armazene dados de cartão, e mantenha o antifraude ativo.
• Restrinja o acesso aos backups e mascare os dados de clientes nos ambientes de homologação.

8. Logs, monitoramento e resposta a incidentes

• Monitore os logs da aplicação (var/log/system.log e var/log/exception.log) e os do servidor web, e centralize-os quando puder.
• Crie alertas para picos de erro, tentativas de login, criação de usuários administrativos e alteração de arquivos críticos.
• Observe o servidor, e não só a aplicação. Na campanha de ataque à CVE-2026-75650, a empresa de segurança Sansec descreveu um processo disfarçado de thread do kernel, tarefas de cron inesperadas e tráfego de comando disfarçado de sincronização de horário. Nada disso aparece em um painel de vendas.
• Designe uma pessoa ou uma empresa responsável pela segurança da loja. Sem dono, o alerta vira ruído.
• Faça uma avaliação de risco e um teste de segurança pelo menos uma vez por ano e depois de mudanças grandes na plataforma.

9. Integrações externas e APIs

• Crie um token específico para cada integração (ERP, CRM, gateway, marketplace) e limite o escopo de cada um.
• Revogue os tokens de integrações desativadas.
• Guarde credenciais em variáveis de ambiente ou em um cofre de segredos, e não no código nem no repositório.
• Registre quais integrações existem e quem responde por cada uma.

10. Segurança no Magento B2B

• Revise as permissões das contas de empresa (Company Accounts) e das funções dos compradores.
• Restrinja o acesso a catálogos e preços compartilhados.
• Audite as regras de aprovação de pedidos.
• Conceda poderes de compra com critério, porque pedidos B2B têm valores e volumes maiores.

11. Backups e plano de contingência

• Faça backup automático do banco e dos arquivos, com cópia fora do servidor principal.
• Teste a restauração em periodicidade definida. Um backup que nunca foi restaurado ainda é uma aposta.
• Documente o plano de resposta a incidentes: quem decide, quem investiga, quem comunica.
• Considere o prazo legal. Quando um incidente expõe dados pessoais e pode causar risco ou dano relevante aos titulares, o regulamento da ANPD (Resolução CD/ANPD nº 15/2024) prevê a comunicação em três dias úteis, contados do conhecimento de que o incidente afetou dados pessoais.

Limitações e riscos que o checklist não elimina

• Falhas desconhecidas podem surgir. O caso da CVE-2026-75650 mostra isso: a Sansec registrou o início dos ataques em 4 de setembro de 2026, e a Adobe publicou o hotfix em 7 de setembro.
• Erros humanos continuam acontecendo, por isso processo e treinamento contam tanto quanto configuração.
• Extensões de terceiros carregam risco próprio.
• Uma camada mal gerenciada compromete as outras.

Por isso, trate segurança como processo contínuo: documente as decisões técnicas, revise a segurança a cada nova integração, mantenha desenvolvimento, homologação e produção separados e faça auditorias periódicas. Para medir o ponto de partida da sua operação, o time pode preencher o checklist de saúde do Magento.

Como a Trezo pode ajudar

A Trezo trabalha só com Magento e Adobe Commerce desde 2009. Revisamos código, infraestrutura e operação, fazemos a sustentação da loja e monitoramos as lojas dos nossos clientes 24 horas por dia, 7 dias por semana. Somos Adobe Solution Partner e AWS Partner, com certificação ISO 27001.

Em lojas com muitas integrações, operação B2B ou alto volume de pedidos, segurança deixa de ser detalhe técnico e vira risco de negócio. Se quiser revisar este checklist com a realidade da sua loja, fale com nossos especialistas.

Perguntas frequentes