A Black Friday concentra em poucos dias uma parte grande do faturamento da loja virtual. É também o período em que uma falha no checkout, um cupom mal configurado ou uma integração instável custa mais caro, porque o volume de pedidos amplia qualquer erro. A revisão de segurança precisa acontecer com antecedência, com tempo para corrigir o que for encontrado e testar de novo antes do pico.

O que o PCI DSS exige da sua loja

O PCI DSS é o padrão de segurança do setor de cartões de pagamento. As obrigações da versão 4.0.1 dependem de como a loja lida com os dados de cartão. Antes de qualquer contratação, o gestor precisa saber em qual situação a empresa se encontra.

Loja que captura dados de cartão no próprio ambiente

Se o cliente digita o número do cartão em uma página hospedada pela própria loja, ou se esses dados passam pelos servidores da empresa, a loja está capturando dados de cartão no próprio ambiente. Nesse caso, o requisito 11.4 do PCI DSS 4.0.1 exige teste de intrusão. Não é uma recomendação: é parte da conformidade exigida de quem aceita cartão dessa forma.

Loja com página de pagamento totalmente terceirizada

Quando todo o pagamento acontece em uma página do provedor, e a loja nunca recebe os dados do cartão, o enquadramento normalmente é o questionário SAQ A. Esse questionário não exige teste de intrusão.

Isso não elimina a responsabilidade da loja. Mesmo com o pagamento terceirizado, a loja precisa se manter protegida contra alteração de scripts nas páginas anteriores ao pagamento. Carrinho, identificação do cliente e escolha de frete são páginas da própria loja. Se um script dessas páginas for modificado sem autorização, o cliente pode ser levado a um destino falso antes de chegar ao provedor legítimo. O controle sobre o que é carregado nessas páginas continua sendo dever da loja.

Confirme com o gateway e com o responsável pela conformidade qual é o enquadramento correto. Uma mudança no checkout, como trocar a página do provedor por um formulário embutido, pode mudar as obrigações. Para entender o tema em detalhe, veja nossa página sobre pentest para PCI DSS.

A LGPD vale para os dados dos clientes

Mesmo quando a loja não toca em dados de cartão, ela trata nome, CPF, endereço, telefone, e-mail e histórico de compras. Todos esses são dados pessoais e estão sob a LGPD. Um vazamento da base de clientes é um problema jurídico e de reputação, independentemente do enquadramento no PCI DSS.

Regras de cupom e preço: risco de negócio

Parte dos prejuízos em datas de pico não vem de invasão, mas de regra comercial mal implementada. Um cupom que pode ser usado mais vezes do que o previsto, um desconto que se acumula com outro sem intenção ou um preço que não é conferido no fechamento do pedido gera perda direta de margem.

Essas falhas raramente aparecem em ferramentas automáticas, porque dependem da lógica do negócio. Antes da campanha, reúna o time comercial e o de tecnologia e responda:

• O valor final do pedido é recalculado e conferido pelo sistema no momento do fechamento, e não apenas exibido na tela?
• Cada cupom tem limite de uso definido, por cliente e no total, e esse limite é aplicado pelo sistema?
• Está documentado quais descontos podem ser combinados e quais não podem?
• Cupons de campanhas antigas, de teste ou de parceiros foram desativados?
• Frete grátis, brindes e condições de parcelamento seguem as mesmas regras em todos os canais, como site e aplicativo?
• Quem pode criar cupons no painel, e existe registro de quem criou cada um?

Controle de acesso na área do cliente

A área do cliente mostra pedidos, endereços, notas fiscais e, às vezes, dados de pagamento parciais. A regra é simples: cada cliente só pode ver e alterar os próprios dados. Quando esse controle falha, um cliente autenticado pode acabar vendo informações de outro, o que configura exposição de dados pessoais.

Pontos que o gestor deve verificar com o time ou com o fornecedor da plataforma:

• O acesso a pedidos, endereços e documentos é conferido pelo sistema a cada solicitação, e não só na tela de login.
• O fluxo de recuperação de senha não revela se um e-mail está cadastrado e não permite tomar a conta de outra pessoa.
• As sessões expiram após um período de inatividade.
• O painel administrativo exige autenticação multifator e tem perfis com permissões diferentes para atendimento, marketing e financeiro.
• Contas de ex-funcionários e de agências que já não prestam serviço foram removidas.

Integrações com gateway e ERP

O checkout depende de vários sistemas: gateway de pagamento, antifraude, cálculo de frete, estoque, ERP e emissão de nota fiscal. Cada integração tem credenciais, permissões e um ponto de falha. Em época de pico, uma integração mal protegida pode expor dados ou liberar pedidos que não foram pagos.

• Inventário: mantenha uma lista atualizada de todas as integrações, com responsável e finalidade.
• Credenciais: cada integração deve ter apenas as permissões necessárias, e as chaves devem ser trocadas quando alguém com acesso sai da empresa ou da agência.
• Confirmação de pagamento: o pedido só deve ser liberado depois que o sistema confirmar o pagamento diretamente com o gateway.
• Falhas: defina o que acontece se o ERP ou o antifraude ficarem indisponíveis durante a campanha.

As interfaces de programação que ligam loja, aplicativo e ERP devem estar no escopo da avaliação. Nossa página de pentest web explica como aplicações e APIs são avaliadas.

Planejamento antes da data de pico

O erro mais comum é deixar a avaliação para as últimas semanas. Um teste feito em cima da hora encontra problemas que não há tempo de corrigir, e ninguém quer mexer no checkout às vésperas da campanha. Uma sequência realista inclui:

• Definir o escopo: loja, área do cliente, painel administrativo, aplicativo, APIs e integrações.
• Contratar a avaliação e combinar a janela de testes, de preferência em ambiente de homologação idêntico à produção.
• Corrigir as falhas priorizadas pelo relatório.
• Fazer o reteste para confirmar as correções.
• Congelar mudanças no checkout e nas regras de promoção até o fim da campanha.
• Deixar definido quem aciona quem em caso de incidente durante o pico.

O que pedir ao fornecedor da avaliação

Nem toda avaliação cobre o que uma loja virtual precisa. Ao cotar, peça:

• Escopo por escrito, incluindo regras de negócio de cupom, preço e frete, e não apenas varredura automática.
• Testes de controle de acesso com contas de perfis diferentes.
• Relatório com evidências, nível de risco de cada achado e recomendação de correção compreensível para o time.
• Resumo executivo para a diretoria.
• Reteste incluído após as correções.
• Acordo de confidencialidade e tratamento dos dados de clientes conforme a LGPD.

Para comparar propostas com critério, leia nosso guia sobre quanto custa um pentest.

A LDL Security avalia lojas virtuais com foco em checkout, regras de promoção, área do cliente e integrações. Conheça nossa página de pentest para e-commerce e planeje a revisão antes da próxima data de pico.

Perguntas Frequentes

Minha loja usa página de pagamento terceirizada. Preciso de pentest?

Pelo PCI DSS 4.0.1, lojas com pagamento totalmente terceirizado normalmente ficam no SAQ A, que não exige teste de intrusão. A loja ainda precisa proteger os scripts das páginas anteriores ao pagamento e cumprir a LGPD, e uma avaliação ajuda a demonstrar esses cuidados.

Quando o teste de intrusão é obrigatório pelo PCI DSS?

O requisito 11.4 do PCI DSS 4.0.1 exige teste de intrusão de quem captura dados de cartão no próprio ambiente, por exemplo quando o cliente digita o cartão em página hospedada pela loja.

Ferramentas automáticas encontram falhas em cupons e preços?

Em geral, não. Essas falhas dependem da lógica do negócio e exigem análise manual de quem entende as regras da campanha. Por isso vale incluí-las no escopo por escrito.

Com quanta antecedência devo fazer a avaliação?

Com tempo suficiente para corrigir os achados, fazer o reteste e congelar mudanças antes da campanha. Combine o cronograma com o fornecedor já na contratação.