A utilização da Stripe torna-o conforme com o PCI?
Não. Utilizar a Stripe reduz o seu âmbito do PCI DSS e pode passá-lo para a autoavaliação SAQ A, mais curta, mas não o torna totalmente conforme. A Stripe certifica os seus próprios sistemas, não o seu site. Os requisitos 6.4.3 e 11.6.1 do PCI DSS 4.0.1 regem os scripts da sua página de pagamento, e essa página continua a ser carregada no navegador do seu cliente. Continuam a ser da sua responsabilidade.
As equipas de comércio eletrónico e de conformidade ignoram muitas vezes esta lacuna. Transferir a captura do cartão para um processador é valioso: retira os dados de titulares de cartão dos seus servidores e reduz o número de controlos que tem de autoatestar. Mas "usamos a Stripe" responde a uma pergunta sobre onde os números de cartão são processados. Não responde à pergunta que o PCI DSS 4.0.1 passou a colocar: o que está cada script a fazer no navegador enquanto o seu cliente escreve os dados do cartão?
O que a Stripe realmente cobre (e o que não cobre)
A Stripe é um prestador de serviços de Nível 1 do PCI DSS, e pode usar a Stripe para reduzir o âmbito do PCI DSS. Quando utiliza o Stripe Elements, os campos alojados (hosted fields) ou o Stripe Checkout, o número do cartão é introduzido num iframe servido e controlado pela Stripe. Os dados sensíveis vão parar ao ambiente da Stripe, não ao seu. É essa a redução de âmbito que está a pagar, e é real.
O que a Stripe não faz é assumir a responsabilidade da página que envolve o seu iframe. A sua página de checkout continua a ser servida a partir do seu domínio, montada pela sua stack e decorada com os seus scripts: analítica, gestores de tags, repetição de sessão (session replay), chat, SDKs antifraude e tudo o que uma equipa de marketing acrescentou no último trimestre. Esses scripts são executados no mesmo navegador que o fluxo de pagamento.
| Preocupação | A Stripe cobre | Continua a ser sua (6.4.3 / 11.6.1) |
|---|---|---|
| Introdução e armazenamento do número do cartão | Sim, dentro do iframe alojado da Stripe | Não |
| Atestação PCI DSS da própria Stripe | Sim, enquanto prestador de serviços de Nível 1 | Não |
| Scripts de terceiros na página de pagamento | Não | Sim, inventariar e justificar cada um (6.4.3) |
| Integridade desses scripts (sem adulteração) | Não | Sim, confirmar a integridade (6.4.3) |
| Deteção de adulteração e de alterações, com alertas | Não | Sim, implementar um mecanismo (11.6.1) |
| Cabeçalhos HTTP com impacto na segurança | Não | Sim, monitorizar alterações não autorizadas (11.6.1) |
| O seu SAQ e AoC enquanto comerciante | Não | Sim, faz a autoavaliação e atesta |
A divisão é clara. A Stripe é dona dos dados do cartão, você é dono do ambiente do navegador que os rodeia. O PCI DSS 4.0.1 tornou essa segunda coluna explícita.
O que exigem, afinal, os requisitos 6.4.3 e 11.6.1?
Ambos os requisitos foram introduzidos para fazer face a ataques do lado do cliente, em que código malicioso é injetado em scripts que são executados no navegador do cliente. Tornaram-se obrigatórios a 31 de março de 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
Requisito 6.4.3: gerir os scripts da página de pagamento. Para cada script carregado e executado na página de pagamento no navegador do consumidor, tem de:
- Manter um inventário de todos os scripts, com justificação escrita do motivo pelo qual cada um é necessário.
- Autorizar cada script antes de ser adicionado ou alterado.
- Confirmar a integridade de cada script, verificando que não foi modificado sem autorização.
Requisito 11.6.1: detetar adulterações e alertar. Tem de implementar um mecanismo de deteção de alterações e de adulteração que:
- Alerte o pessoal para modificações não autorizadas dos cabeçalhos HTTP e dos scripts da página de pagamento, tal como recebidos pelo navegador do consumidor.
- Avalie a página recebida pelo menos a cada sete dias, ou com a frequência definida pela sua análise de risco direcionada.
O 6.4.3 diz para conhecer e autorizar os seus scripts, e o 11.6.1 diz para os vigiar em tempo real e alertar quando mudam. Nenhum é satisfeito pelo seu processador de pagamentos, porque nenhum tem a ver com o destino dos dados do cartão. Têm a ver com o que é executado no navegador. Para um passo a passo detalhado, consulte o nosso guia prático sobre a conformidade com os requisitos 6.4.3 e 11.6.1 do PCI.
Estes requisitos aplicam-se-me se estiver em SAQ A?
As equipas são apanhadas aqui. O SAQ A é a autoavaliação mais curta, reservada a comerciantes que externalizam totalmente o tratamento dos dados de titulares de cartão. É tentador ler "totalmente externalizado" como "nada do lado do cliente com que se preocupar". Já não é assim que o PCI SSC o encara.
O SAQ A de janeiro de 2025 removeu o 6.4.3 e o 11.6.1 do próprio questionário e, no lugar deles, acrescentou um novo critério de elegibilidade. Para usar o SAQ A passou a ter de confirmar que a sua página de pagamento não é suscetível a ataques de scripts que possam afetar os seus sistemas de comércio eletrónico, e que todos os elementos entregues ao navegador têm origem direta num processador conforme com o PCI DSS (PCI Security Standards Council, 2025). Os comerciantes que não conseguem fazer essa confirmação saem do SAQ A e têm de cumprir diretamente os requisitos relativos aos scripts da página de pagamento. De uma forma ou de outra, o risco dos scripts do lado do navegador é agora um problema seu. Confirme a versão atual do seu SAQ A e os respetivos critérios de elegibilidade na Document Library do PCI SSC antes de assumir que está fora do âmbito.
A alteração remonta a um acontecimento específico. O incidente da Polyfill[.]io em 2024 mostrou como um único script de terceiros de confiança, incorporado em mais de 490 000 sites, pode ser tornado malicioso de um dia para o outro e servir código de skimming ou de redirecionamento a páginas de checkout (Sansec, 2024). Um comerciante em SAQ A com o Stripe Checkout estava tão exposto como qualquer outro, porque o script malicioso entrou pela própria página do comerciante, não pela da Stripe.
Por que motivo a página de pagamento continua a ser a sua superfície de ataque
O problema de fundo é onde o código é executado. O iframe da Stripe isola os campos do cartão, mas os ataques do lado do cliente raramente visam diretamente o campo do cartão. Visam a página à volta dele.
- Sobreposições de formulários. Um script comprometido pode desenhar um formulário de cartão falso por cima, ou ao lado, do iframe da Stripe e capturar os dados antes de chegarem à Stripe.
- Redirecionamento do checkout. Código injetado pode enviar um comprador para uma página de pagamento falsa a meio do fluxo.
- Recolha de dados. Um script de analítica ou de chat adulterado pode ler o nome, o e-mail, a morada e os detalhes da encomenda a partir do DOM e exfiltrá-los para um domínio controlado pelo atacante.
- Enfraquecimento de cabeçalhos. Cabeçalhos HTTP com impacto na segurança modificados, como o Content-Security-Policy, podem abrir a porta aos scripts acima, e é por isso que o 11.6.1 nomeia explicitamente os cabeçalhos.
O e-skimming não é um caso-limite raro. O web skimming ao estilo Magecart atingiu milhares de sites de comércio eletrónico, e a técnica persiste porque o navegador é difícil de monitorizar a partir do servidor. No Verizon DBIR de 2024, os dados de cartões de pagamento representaram 25% dos registos comprometidos no setor do retalho, e o retalho é apontado como o terreno habitual dos atores Magecart que inserem código malicioso nas páginas de checkout (Verizon, 2024). Tanto os registos do seu servidor como o painel da Stripe parecerão normais enquanto um skimmer corre nos navegadores dos seus clientes.
É por isso que os requisitos vivem no navegador, e não no backend. Para perceber como estes ataques contornam os controlos do lado do servidor, consulte o nosso guia sobre segurança do lado do cliente.
Como cumprir os requisitos 6.4.3 e 11.6.1 na prática
Pode cumprir estes requisitos manualmente: manter uma folha de cálculo com todos os scripts, justificar cada um, gerar os respetivos hashes e verificar semanalmente a página de pagamento renderizada à procura de alterações. Para um site com um punhado de scripts estáticos, isso talvez se aguente. Para um checkout real, em que um gestor de tags injeta scripts dinamicamente, a abordagem manual rapidamente se desmorona e produz provas de que os auditores desconfiam.
A resposta operacional é a monitorização de scripts contínua e automatizada, concebida para a página de pagamento. A cside PCI Shield foi pensada para cumprir diretamente ambos os requisitos:
- Inventário e justificação automatizados (6.4.3). A cside deteta todos os scripts em execução na sua página de pagamento, cria o inventário e permite-lhe registar a autorização e a justificação num só local, com revisão num clique e assistida por IA.
- Integridade e deteção de adulteração em tempo real (11.6.1). A cside monitoriza continuamente os scripts e os cabeçalhos HTTP com impacto na segurança e alerta para alterações não autorizadas, em vez de amostrar com um cron semanal e torcer para que nada tenha escapado entre verificações.
- Provas prontas para auditoria. A cside arquiva todas as versões de cada script com o histórico completo, para que entregue a um QSA registos forenses em vez de suposições comportamentais.
A ideia não é substituir a Stripe. A Stripe e uma camada de monitorização de scripts resolvem metades diferentes do mesmo retrato de conformidade: a Stripe tira os dados do cartão do âmbito, e a cside cobre os requisitos do lado do navegador que a Stripe lhe deixa.
Conclusão
Utilizar a Stripe é uma forma inteligente de reduzir o âmbito do PCI, e pode colocá-lo em SAQ A. Não o torna totalmente conforme com o PCI, porque os requisitos 6.4.3 e 11.6.1 responsabilizam-no pelos scripts e cabeçalhos da sua página de pagamento, onde os campos alojados da Stripe não chegam. Esses requisitos são obrigatórios, e a própria elegibilidade para o SAQ A depende agora de confirmar que a sua página de pagamento está protegida contra a adulteração de scripts.
Trate a página de pagamento como a sua superfície de ataque, inventarie e autorize cada script e implemente deteção de adulteração em tempo real. Para a vertente operacional disso, consulte a cside PCI Shield e a segurança do lado do cliente, ou marque uma demonstração para percorrermos o seu checkout.
