Uma loja virtual tem uma característica que muda completamente a conversa sobre segurança: ela processa dinheiro e guarda dados de pessoas que confiaram na empresa.

Isso cria dois tipos de responsabilidade que um site institucional não tem. A primeira é operacional — uma loja comprometida gera prejuízo direto e imediato. A segunda é jurídica — dados de clientes estão sob a proteção da LGPD, e vazamentos têm consequências que vão além do incidente técnico.

Este guia trata do que é específico de uma loja: o que você processa, o que você guarda, o que é responsabilidade do meio de pagamento e onde estão os riscos que realmente importam. As medidas gerais de proteção de um site WordPress — atualizações, controle de acesso, ambiente — estão no artigo sobre segurança no WordPress, e valem integralmente aqui.

O que sua loja realmente guarda

Comece por um inventário, porque a maioria dos lojistas subestima o que está armazenado.

Tipo de dado	Onde costuma estar	Sensibilidade
Nome, e-mail e telefone	Banco de dados da loja	Dado pessoal
Endereço completo	Banco de dados da loja	Dado pessoal
CPF ou CNPJ	Banco de dados da loja	Dado pessoal
Histórico de compras	Banco de dados da loja	Dado pessoal, revela hábitos
Senha do cliente	Banco, de forma cifrada	Crítico se comprometido
Dados do cartão	Idealmente, em lugar nenhum	Altamente sensível

A última linha é a mais importante deste artigo e merece a próxima seção inteira.

As demais deveriam receber mais atenção do que recebem. Um vazamento de base de clientes é mais provável e, em muitos casos, mais danoso que um problema com cartão — porque o cartão tem mecanismos de contestação e substituição, enquanto endereço, CPF e histórico de compras não podem ser trocados.

Dados de cartão: a regra que resolve

Existe uma orientação que simplifica drasticamente a segurança de pagamentos: não guarde dados de cartão.

A forma padrão de operar hoje é delegar o processamento ao meio de pagamento. Existem duas abordagens comuns:

Redirecionamento. O cliente é levado ao ambiente do meio de pagamento para inserir os dados e volta à loja depois. Os dados nunca passam pelo seu servidor.

Campos incorporados. O formulário aparece dentro da sua página, mas os campos pertencem tecnicamente ao meio de pagamento, e os dados vão direto para ele. Visualmente é a sua loja; tecnicamente, os dados não tocam o seu ambiente.

Em ambos os casos, o que retorna para a loja é um identificador da transação, e não o número do cartão. Isso significa que um comprometimento da sua loja não expõe dados de cartão — simplesmente porque eles não estão lá.

Sobre o PCI DSS, que é o conjunto de normas do setor de cartões: as exigências aplicáveis dependem de como os dados trafegam. Quando a loja não captura nem armazena dados de cartão, o escopo é substancialmente reduzido — mas não desaparece, porque a integridade da página de checkout continua importando. O modelo aplicável ao seu caso é uma pergunta para o seu meio de pagamento, e vale fazê-la explicitamente.

O ataque específico de lojas

Vale conhecer, porque ele é diferente do que atinge sites comuns.

Em um site institucional, um comprometimento costuma resultar em redirecionamentos, páginas de spam ou uso do servidor para outros fins. O objetivo é o servidor.

Em uma loja, existe um ataque cujo objetivo é a página de checkout: código malicioso injetado que captura os dados digitados pelo cliente e os envia para outro lugar, enquanto a compra prossegue normalmente.

O que torna esse ataque perigoso:

• A loja continua funcionando. Pedidos entram, pagamentos são aprovados, nada parece errado.
• O cliente não percebe. Ele conclui a compra e recebe o produto.
• A detecção é difícil. O código pode ser carregado apenas para uma parcela dos visitantes, ou apenas em determinados horários.
• A descoberta costuma ser externa — pelo meio de pagamento, por uma bandeira ou por um cliente que sofreu fraude e rastreou a origem.

O que reduz o risco:

1. Monitorar a integridade dos arquivos, com alerta quando algo muda sem que ninguém tenha publicado nada.
2. Controlar rigorosamente quais scripts de terceiros carregam no checkout. Cada script externo é um ponto de entrada, e páginas de pagamento acumulam pixels e ferramentas de análise.
3. Restringir acesso administrativo, já que a injeção quase sempre entra por uma credencial ou por um plugin vulnerável.
4. Manter tudo atualizado, pelo motivo de sempre.

O segundo item merece decisão consciente: scripts de rastreamento na página de checkout são um risco real. Vale avaliar quais são efetivamente necessários ali, em vez de replicar automaticamente o que roda no resto do site.

A cadeia de responsabilidade

Uma confusão comum que vale esclarecer, porque ela leva a lacunas.

O meio de pagamento é responsável pelo processamento da transação, pela conformidade da infraestrutura dele e, tipicamente, pelas ferramentas antifraude que oferece.

A loja é responsável por tudo o que está no ambiente dela: a integridade das páginas, a segurança do servidor, o controle de acesso, a proteção do banco de dados com os dados dos clientes e a conformidade do tratamento desses dados.

O provedor de hospedagem é responsável pela infraestrutura, e o escopo exato depende do modelo contratado — o assunto do artigo sobre Cloud Server gerenciado ou autogerenciado.

A lacuna aparece quando cada parte presume que a outra cobre algo. Um exemplo concreto: antifraude de transação é do meio de pagamento; segurança da página onde o cliente digita é sua. Ter um bom antifraude não protege contra um checkout comprometido.

LGPD em loja virtual

Uma loja processa dados pessoais por natureza, o que a coloca claramente no alcance da lei. Sem entrar em interpretação jurídica, alguns pontos de atenção práticos:

• Coletar apenas o necessário. Campos extras no cadastro que ninguém usa são dados que você guarda sem propósito e precisa proteger.
• Ter clareza sobre a base legal de cada tratamento — execução do contrato é diferente de consentimento para marketing.
• Separar consentimento de marketing da compra. Cadastro de cliente e autorização para receber campanhas são coisas distintas.
• Definir política de retenção. Dados de pedidos têm exigências fiscais e contábeis; dados de marketing não têm o mesmo prazo.
• Saber onde os dados estão, incluindo os que plugins e integrações enviam para fora da loja.
• Ter um plano para incidentes, porque a lei prevê comunicação em caso de vazamento.

O quinto item costuma revelar surpresas. Plugins de análise, ferramentas de recuperação de carrinho, integrações de marketing e serviços de chat frequentemente enviam dados de clientes para fora — e isso raramente é mapeado. Vale fazer esse inventário uma vez.

Para as decisões que envolvem prazos legais e base jurídica, orientação especializada é o caminho. O que este artigo estabelece é que essas perguntas existem e precisam de resposta, não quais são as respostas.

O que proteger no ambiente

Medidas específicas de loja, complementares às gerais de um site WordPress:

Contas e acessos

• Autenticação em duas etapas obrigatória para todos os acessos administrativos, sem exceção.
• Permissões mínimas. Quem gerencia pedidos não precisa poder instalar plugins.
• Acessos nomeados, para revogação individual e rastreabilidade.
• Revisão periódica de usuários, incluindo acessos de agências e desenvolvedores antigos.

Banco de dados

• Backup com restauração testada, com atenção à retenção — um comprometimento descoberto tarde exige cópias antigas.
• Acesso restrito, sem exposição do banco à internet.
• Retenção consciente, considerando que dados antigos de clientes que você não precisa mais são risco sem contrapartida.

Páginas de pagamento

• HTTPS em todo o site, e não apenas no checkout — conteúdo misto quebra a proteção.
• Monitoramento de integridade das páginas do fluxo de compra.
• Revisão dos scripts que carregam no checkout.
• Teste periódico do fluxo completo, que também detecta comportamento anômalo.

Sinais de que algo está errado

Comprometimentos em loja são discretos por design. O que observar:

• Reclamações de fraude por parte de clientes que compraram recentemente.
• Contato do meio de pagamento sobre padrão anômalo de transações.
• Arquivos modificados em datas que não correspondem a nenhuma publicação.
• Pedidos com padrão estranho — valores repetidos, muitos cartões diferentes, tentativas sucessivas de aprovação.
• Usuários administrativos que ninguém criou.
• Comportamento diferente do checkout para alguns visitantes ou dispositivos.

O quarto item merece nota porque tem outra origem possível: lojas são usadas para testar cartões roubados, com pequenas transações sucessivas para verificar quais números funcionam. Isso gera custo de taxas, prejudica a reputação junto ao meio de pagamento e pode passar por movimento normal se ninguém acompanhar.

Se algo assim aparecer, o procedimento é o mesmo de qualquer comprometimento: isolar, trocar credenciais e buscar ajuda técnica antes de restaurar — porque restaurar sem entender a origem reintroduz a falha.

Conclusão

A segurança de uma loja virtual se organiza em torno de uma decisão que simplifica tudo: não guardar dados de cartão. Delegando o processamento ao meio de pagamento, um comprometimento da loja não expõe esses dados, porque eles não estão lá.

O que sobra sob sua responsabilidade é mais amplo do que parece: a integridade das páginas onde o cliente digita, o controle de acesso ao ambiente e a proteção da base de dados com nome, endereço, documento e histórico de compras — informações que, diferentemente de um cartão, não podem ser substituídas.

E a lacuna mais comum: antifraude é do meio de pagamento; a página onde o cliente digita é sua. Se a sua loja processa volume relevante, vale avaliar um ambiente com controle sobre o servidor e monitoramento de integridade. Conheça o Cloud Server para WooCommerce da TBF Host e avalie o ambiente adequado à sua operação.

Perguntas frequentes

Minha loja WooCommerce guarda dados de cartão?

Não deveria. A forma padrão de operar é delegar o processamento ao meio de pagamento, seja por redirecionamento, seja por campos incorporados que pertencem tecnicamente a ele. Nos dois casos, o que retorna à loja é um identificador da transação, e um comprometimento não expõe dados de cartão porque eles não estão lá.

Preciso me preocupar com PCI DSS na minha loja?

As exigências aplicáveis dependem de como os dados de cartão trafegam. Quando a loja não captura nem armazena esses dados, o escopo é substancialmente reduzido — mas não desaparece, porque a integridade da página de checkout continua importando. O modelo aplicável ao seu caso é uma pergunta para o seu meio de pagamento.

O que é injeção de código no checkout?

É um ataque específico de lojas em que código malicioso é inserido na página de pagamento para capturar os dados digitados pelo cliente e enviá-los a terceiros, enquanto a compra prossegue normalmente. A loja continua funcionando, o cliente não percebe, e a descoberta costuma vir de fora — do meio de pagamento ou de um cliente que sofreu fraude.

Scripts de rastreamento no checkout são um risco?

São. Cada script de terceiro carregado na página de pagamento é um ponto de entrada potencial, e páginas de checkout costumam acumular pixels e ferramentas de análise replicados automaticamente do resto do site. Vale decidir conscientemente quais são efetivamente necessários ali.

De quem é a responsabilidade pela segurança da loja?

O meio de pagamento responde pelo processamento da transação e pelas ferramentas antifraude que oferece. A loja responde pela integridade das próprias páginas, pelo controle de acesso, pela segurança do servidor e pela proteção dos dados de clientes. O provedor responde pela infraestrutura, no escopo do modelo contratado.

O que uma loja precisa observar em relação à LGPD?

Coletar apenas dados necessários, ter clareza sobre a base legal de cada tratamento, separar consentimento de marketing da compra, definir política de retenção considerando as exigências fiscais dos pedidos, mapear para onde plugins e integrações enviam dados e ter um plano para comunicação em caso de incidente.

Recebi vários pedidos pequenos e estranhos. O que pode ser?

Um padrão possível é o uso da loja para testar cartões roubados, com transações sucessivas de baixo valor para verificar quais números funcionam. Isso gera custo de taxas, prejudica a reputação junto ao meio de pagamento e pode passar por movimento normal se ninguém acompanhar o padrão de pedidos.

O que fazer se a loja for comprometida?

Isolar o ambiente, trocar todas as credenciais administrativas e de hospedagem, e buscar ajuda técnica antes de restaurar um backup. Restaurar sem entender a origem costuma reintroduzir a falha. Também é necessário avaliar a obrigação de comunicar o incidente, já que dados pessoais de clientes podem ter sido expostos.