L'utilisation de Stripe vous rend-elle conforme à la norme PCI ?
Non. Utiliser Stripe réduit votre périmètre PCI DSS et peut vous faire passer à l'auto-évaluation SAQ A, plus courte, mais cela ne vous rend pas pleinement conforme. Stripe certifie ses propres systèmes, pas votre site web. Les exigences 6.4.3 et 11.6.1 de la norme PCI DSS 4.0.1 régissent les scripts présents sur votre page de paiement, et cette page se charge toujours dans le navigateur de votre client. Elles restent de votre responsabilité.
Les équipes e-commerce et conformité négligent souvent cette faille. Déléguer la collecte des données de carte à un prestataire est précieux : cela retire les données de titulaires de cartes de vos serveurs et réduit le nombre de contrôles que vous attestez vous-même. Mais « nous utilisons Stripe » répond à une question sur l'endroit où les numéros de carte sont traités. Cela ne répond pas à la question que la norme PCI DSS 4.0.1 pose désormais : que fait chaque script dans le navigateur pendant que votre client saisit sa carte ?
Ce que Stripe couvre réellement (et ce qu'il ne couvre pas)
Stripe est un prestataire de services PCI DSS de niveau 1, et vous pouvez utiliser Stripe pour réduire votre périmètre PCI DSS. Lorsque vous utilisez Stripe Elements, les champs hébergés ou Stripe Checkout, le numéro de carte est saisi dans une iframe servie et contrôlée par Stripe. Les données sensibles aboutissent dans l'environnement de Stripe, pas le vôtre. C'est la réduction de périmètre que vous payez, et elle est bien réelle.
Ce que Stripe ne fait pas, c'est assumer la responsabilité de la page qui entoure son iframe. Votre page de paiement est toujours servie depuis votre domaine, assemblée par votre stack, et garnie de vos scripts : analytique, gestionnaires de balises, rejeu de session, chat, SDK de lutte contre la fraude, et tout ce qu'une équipe marketing a ajouté le trimestre dernier. Ces scripts s'exécutent dans le même navigateur que le flux de paiement.
| Préoccupation | Stripe le couvre | Cela reste à votre charge (6.4.3 / 11.6.1) |
|---|---|---|
| Saisie et stockage du numéro de carte | Oui, dans l'iframe hébergée de Stripe | Non |
| Attestation PCI DSS propre à Stripe | Oui, en tant que prestataire de services de niveau 1 | Non |
| Scripts tiers sur la page de paiement | Non | Oui, inventorier et justifier chacun (6.4.3) |
| Intégrité de ces scripts (absence d'altération) | Non | Oui, confirmer l'intégrité (6.4.3) |
| Détection des altérations et modifications, plus alertes | Non | Oui, déployer un mécanisme (11.6.1) |
| En-têtes HTTP ayant un impact sur la sécurité | Non | Oui, surveiller toute modification non autorisée (11.6.1) |
| Votre SAQ et votre AoC de commerçant | Non | Oui, vous vous auto-évaluez et attestez |
Le partage est net. Stripe est propriétaire des données de carte, vous êtes propriétaire de l'environnement navigateur qui les entoure. La norme PCI DSS 4.0.1 a rendu cette seconde colonne explicite.
Qu'imposent réellement les exigences 6.4.3 et 11.6.1 ?
Les deux exigences ont été introduites pour répondre aux attaques côté client, où du code malveillant est injecté dans des scripts qui s'exécutent dans le navigateur du client. Elles sont devenues obligatoires le 31 mars 2025 (PCI Security Standards Council, PCI DSS v4.0.1).
Exigence 6.4.3 : gérez les scripts de votre page de paiement. Pour chaque script chargé et exécuté sur la page de paiement dans le navigateur du consommateur, vous devez :
- Tenir un inventaire de tous les scripts, avec une justification écrite de la nécessité de chacun.
- Autoriser chaque script avant son ajout ou sa modification.
- Confirmer l'intégrité de chaque script en vérifiant qu'il n'a pas été modifié sans autorisation.
Exigence 11.6.1 : détectez les altérations et alertez. Vous devez déployer un mécanisme de détection des modifications et des altérations qui :
- Alerte le personnel en cas de modification non autorisée des en-têtes HTTP et des scripts de la page de paiement, telle qu'elle est reçue par le navigateur du consommateur.
- Évalue la page reçue au moins une fois tous les sept jours, ou à une fréquence définie par votre analyse de risque ciblée.
La 6.4.3 dit de connaître et d'autoriser vos scripts, et la 11.6.1 dit de les surveiller en temps réel et d'alerter lorsqu'ils changent. Ni l'une ni l'autre n'est satisfaite par votre prestataire de paiement, car aucune ne porte sur l'endroit où vont les données de carte. Elles portent sur ce qui s'exécute dans le navigateur. Pour une marche à suivre étape par étape, consultez notre guide pratique sur la conformité aux exigences PCI 6.4.3 et 11.6.1.
Ces exigences s'appliquent-elles à moi si je suis en SAQ A ?
Les équipes se font piéger ici. Le SAQ A est l'auto-évaluation la plus courte, réservée aux commerçants qui externalisent entièrement le traitement des données de titulaires de cartes. Il est tentant de lire « entièrement externalisé » comme « rien à craindre côté client ». Ce n'est plus ainsi que le PCI SSC le considère.
Le SAQ A de janvier 2025 a retiré les exigences 6.4.3 et 11.6.1 du questionnaire lui-même, puis a ajouté un nouveau critère d'éligibilité à leur place. Pour utiliser le SAQ A, vous devez désormais confirmer que votre page de paiement n'est pas vulnérable aux attaques provenant de scripts susceptibles d'affecter vos systèmes de commerce électronique, et que chaque élément transmis au navigateur provient directement d'un prestataire conforme à la norme PCI DSS (PCI Security Standards Council, 2025). Les commerçants qui ne peuvent pas faire cette confirmation sortent du SAQ A et doivent satisfaire directement aux exigences relatives aux scripts de la page de paiement. Dans les deux cas, le risque lié aux scripts côté navigateur est désormais votre problème. Vérifiez la version actuelle de votre SAQ A et ses critères d'éligibilité dans la bibliothèque de documents du PCI SSC avant de présumer que vous êtes hors périmètre.
Ce changement trouve son origine dans un événement précis. L'incident Polyfill[.]io de 2024 a montré comment un seul script tiers de confiance, intégré sur plus de 490 000 sites, peut être rendu malveillant du jour au lendemain et servir du code de skimming ou de redirection aux pages de paiement (Sansec, 2024). Un commerçant en SAQ A utilisant Stripe Checkout était tout aussi exposé que n'importe qui d'autre, car le script malveillant s'introduisait via la propre page du commerçant, pas celle de Stripe.
Pourquoi la page de paiement reste votre surface d'attaque
Le problème fondamental, c'est l'endroit où le code s'exécute. L'iframe de Stripe isole les champs de carte, mais les attaques côté client ciblent rarement le champ de carte directement. Elles ciblent la page qui l'entoure.
- Superpositions de formulaire. Un script compromis peut dessiner un faux formulaire de carte par-dessus, ou à côté de l'iframe de Stripe, et capturer les données avant qu'elles n'atteignent Stripe.
- Redirection du paiement. Du code injecté peut envoyer un acheteur vers une page de paiement falsifiée en plein flux.
- Collecte de données. Un script analytique ou de chat altéré peut lire le nom, l'e-mail, l'adresse et les détails de commande depuis le DOM et les exfiltrer vers un domaine contrôlé par un attaquant.
- Affaiblissement des en-têtes. Des en-têtes HTTP ayant un impact sur la sécurité, comme Content-Security-Policy, modifiés peuvent ouvrir la porte aux scripts ci-dessus, ce qui explique pourquoi la 11.6.1 nomme explicitement les en-têtes.
L'e-skimming n'est pas un cas marginal rare. Le web skimming de type Magecart a frappé des milliers de sites e-commerce, et la technique persiste parce que le navigateur est difficile à surveiller depuis le serveur. Dans le rapport Verizon DBIR de 2024, les données de cartes de paiement représentaient 25 % des enregistrements compromis dans le secteur de la vente au détail, et la vente au détail est désignée comme le terrain de prédilection des acteurs Magecart qui insèrent du code malveillant dans les pages de paiement (Verizon, 2024). Vos journaux de serveur et le tableau de bord de Stripe paraîtront tous deux normaux pendant qu'un skimmer s'exécute dans le navigateur de vos clients.
C'est pourquoi les exigences résident dans le navigateur, pas dans le backend. Pour comprendre comment ces attaques contournent les contrôles côté serveur, consultez notre guide sur la sécurité côté client.
Comment satisfaire aux exigences 6.4.3 et 11.6.1 en pratique
Vous pouvez répondre à ces exigences manuellement : tenir un tableur de chaque script, justifier chacun, en calculer les empreintes, et vérifier chaque semaine la page de paiement rendue pour détecter les modifications. Pour un site avec une poignée de scripts statiques, cela peut tenir. Pour une véritable page de paiement où un gestionnaire de balises injecte des scripts de façon dynamique, l'approche manuelle s'effondre rapidement et produit des preuves auxquelles les auditeurs ne se fient pas.
La réponse opérationnelle est une surveillance des scripts continue et automatisée, conçue pour la page de paiement. cside PCI Shield est conçu pour satisfaire directement aux deux exigences :
- Inventaire et justification automatisés (6.4.3). cside découvre chaque script s'exécutant sur votre page de paiement, construit l'inventaire, et vous permet d'enregistrer l'autorisation et la justification en un seul endroit, avec une revue en un clic et assistée par l'IA.
- Détection en temps réel de l'intégrité et des altérations (11.6.1). cside surveille en continu les scripts et les en-têtes HTTP ayant un impact sur la sécurité, et alerte en cas de modification non autorisée, au lieu d'échantillonner via une tâche cron hebdomadaire en espérant que rien n'ait échappé entre deux vérifications.
- Preuves prêtes pour l'audit. cside archive chaque version de script avec un historique complet, de sorte que vous remettez à un QSA des preuves médico-légales plutôt que des conjectures comportementales.
L'objectif n'est pas de remplacer Stripe. Stripe et une couche de surveillance des scripts résolvent deux moitiés différentes du même tableau de conformité : Stripe sort les données de carte du périmètre, et cside couvre les exigences côté navigateur que Stripe vous laisse.
En résumé
Utiliser Stripe est un moyen judicieux de réduire le périmètre PCI, et cela peut vous placer en SAQ A. Cela ne vous rend pas pleinement conforme à la norme PCI, car les exigences 6.4.3 et 11.6.1 vous tiennent responsable des scripts et des en-têtes de votre page de paiement, là où les champs hébergés de Stripe n'ont aucune portée. Ces exigences sont obligatoires, et l'éligibilité même au SAQ A dépend désormais de la confirmation que votre page de paiement est protégée contre l'altération des scripts.
Traitez la page de paiement comme votre surface d'attaque, inventoriez et autorisez chaque script, et déployez une détection des altérations en temps réel. Pour le volet opérationnel, consultez cside PCI Shield et la sécurité côté client, ou réservez une démo pour passer en revue votre page de paiement.
