La norme de sécurité des données de l'industrie des cartes de paiement (PCI DSS) est la référence en matière de protection des données des titulaires de cartes. Dans sa version actuelle, elle impose aux équipes API des exigences plus strictes que jamais. Voici où en est la norme aujourd'hui, quelles exigences pèsent le plus sur vos API et comment Salt vous aide à les respecter.
État actuel de la norme
La version actuelle publiée est la norme PCI DSS v4.0.1. Le Conseil l'a publiée le 11 juin 2024 en tant que révision limitée visant à clarifier les exigences existantes sans en ajouter ni en supprimer, et la version 4.0 a été retirée le 31 décembre 2024.
Le changement le plus important concerne le calendrier. La version 4.x a introduit 64 nouvelles exigences, et 51 d'entre elles étaient assorties d'une date d'entrée en vigueur fixée au 31 mars 2025. Pour toute évaluation actuelle, il s'agit d'exigences à part entière et non plus de simples objectifs à long terme. Si votre programme de sécurité des API a été défini en fonction de la période de transition, c'est le moment de le réévaluer.
Le Conseil a lancé un appel à commentaires sur la version 4.0.1 jusqu'en juillet 2026 afin de préparer la prochaine itération. Aucune version ultérieure n'ayant été publiée, c'est la version 4.0.1 qui servira de base à votre évaluation.
La chaîne de contrôle PCI de Salt
Les API sont concernées par la norme PCI DSS à chaque étape du cycle de vie logiciel, c'est pourquoi Salt couvre l'ensemble de la chaîne plutôt qu'un seul point de contrôle. La plateforme de sécurité agentique fonctionne depuis l'extérieur de votre périmètre, à travers votre code, jusqu'à votre trafic en temps réel :
- Salt Surface effectue des analyses depuis Internet vers l'intérieur sans déploiement, identifiant les API exposées et les points de terminaison agentiques accessibles depuis l'extérieur. Idéal pour la découverte du périmètre et pour révéler des points de terminaison publics non documentés.
- Salt Connect fonctionne de l'intérieur vers l'extérieur grâce à des intégrations sans agent avec les fournisseurs cloud, les passerelles API et IA, les bases de données et les plateformes d'hébergement, produisant un inventaire et une posture au niveau de la configuration sans intercepter le trafic.
- Découverte continue d'API maintient une vue en temps réel des API internes, externes, tierces, fantômes et zombies, avec métadonnées de point de terminaison, méthode d'authentification, classification des données et modèles de trafic associés.
- Découverte de données sensibles classe les API traitant des données PCI et autres données réglementées, cartographie les chemins d'accès, signale les données sensibles sur des points de terminaison publics ou non authentifiés et valide la protection de la couche de transport.
- Salt Code applique des politiques de sécurité et de conformité au sein des assistants de codage IA, des pull requests et des pipelines CI/CD, et examine les dépôts existants pour détecter les absences d'authentification, les données sensibles non protégées, les secrets codés en dur et les modèles de journalisation risqués.
- Gouvernance de la posture et Policy Hub définissent des normes de posture avec une prise en charge prête à l'emploi du cadre PCI DSS, détectent les dérives, font remonter les violations et exportent des preuves pour les processus d'audit.
- Salt Collect observe le trafic en temps réel sur plus de 70 technologies, fournissant des données comportementales d'exécution que la configuration et l'examen du code ne peuvent produire seuls.
- Salt Protect détecte les abus d'API et les attaques par logique métier grâce à l'établissement de bases de référence comportementales et prend en charge le blocage ciblé.
- Salt Managed Rules pour AWS WAF s'attachent aux ACL web AWS WAF pour le blocage en ligne des classes d'attaques d'API.
- Le graphe de sécurité agentique corrèle l'exposition externe, la configuration, le code et l'exécution, afin que vous puissiez déterminer quel risque lié à une API de paiement est réellement important.
C'est cette chaîne qui permet à la cartographie des exigences ci-dessous de résister à l'évaluation.
Exigence par exigence
6.2.1 et 6.2.3 : développement sécurisé et revue de code
La section 6.2.1 exige que les logiciels sur mesure et personnalisés soient développés de manière sécurisée, en respectant les normes du secteur et les pratiques de développement sécurisé. La section 6.2.3 impose une revue de code adaptée au code produit, et 6.2.3.1 ajoute des contrôles d'indépendance, de connaissances et d'approbation lorsque ces revues sont effectuées manuellement.
Salt Code a été conçu précisément pour cela. Il applique votre politique dès l'écriture du code, directement au sein des assistants de codage IA que vos développeurs utilisent déjà, et analyse les dépôts existants selon cette même politique. Les résultats sont fournis avec des références de fichiers et de lignes, une catégorie et des conseils de remédiation, offrant ainsi un format exploitable par les ingénieurs et lisible par les auditeurs.
Votre propre processus de revue garantit l'indépendance du réviseur et l'approbation de la direction requises par la section 6.2.3.1, en complément des étapes de formation et d'approbation de votre cycle de vie de développement logiciel (SDLC). Salt Code fournit à ces réviseurs des données de bien meilleure qualité pour travailler.
6.2.4 : attaques logicielles courantes, y compris l'abus de logique métier
Il s'agit de l'exigence de la norme qui se rapproche le plus d'une sécurité dédiée aux API. La section 6.2.4 demande la mise en œuvre de techniques d'ingénierie logicielle permettant de prévenir ou d'atténuer les attaques logicielles courantes, et elle mentionne explicitement l'abus de logique métier par la manipulation d'API, de protocoles et de fonctionnalités côté client, ainsi que les attaques contre les mécanismes de contrôle d'accès.
Les failles de logique métier sont la raison pour laquelle la sécurité des API nécessite une approche spécifique. Il n'existe pas de CVE pour un point de terminaison qui permet à un utilisateur authentifié de récupérer les données bancaires d'un autre utilisateur simplement en modifiant un identifiant. La requête est correctement formée, les identifiants sont valides et le canal est chiffré. Ce qui constitue une attaque, c'est le comportement, et c'est précisément ce que Salt a été conçu pour détecter.
Salt couvre cette exigence aux deux extrémités du cycle de vie. Avant la mise en production, Salt Code applique des politiques d'authentification, d'autorisation, de protection des données sensibles et de conception sécurisée. Après le déploiement, les solutions Collect et Protect établissent une base de référence du comportement normal à travers les attributs des API et des utilisateurs afin de faire ressortir les prises de contrôle de compte, l'exfiltration de données, l'abus de session, l'abus de contrôle d'accès et les attaques lentes et furtives. Peu de contrôles dans votre pile technologique permettent de couvrir les deux aspects de la section 6.2.4 aussi efficacement que cette combinaison.
6.3.1 et 6.3.2 : vulnérabilités et inventaire
La section 6.3.1 exige l'identification et la gestion des vulnérabilités avec des classements de risque attribués pour les logiciels sur mesure, personnalisés et tiers. La section 6.3.2 exige un inventaire des logiciels sur mesure et personnalisés, ainsi que des composants logiciels tiers qui y sont intégrés, maintenu à jour pour soutenir la gestion des vulnérabilités et des correctifs.
Salt Code, Posture Governance et le contexte d'exécution identifient les risques liés aux API et aux applications, puis les hiérarchisent en fonction de l'exposition, des données sensibles et du comportement observé. Surface, Connect et la découverte continue vous offrent une vision de votre surface d'attaque personnalisée qui reste à jour au fil des changements système, plutôt qu'une vision obsolète dès le déploiement suivant.
Pour une couverture complète de la section 6.3.2, associez votre inventaire d'API Salt à votre inventaire de composants logiciels ou SBOM. Les deux sont complémentaires : le vôtre répertorie les composants, tandis que Salt répertorie les interfaces que ces composants exposent réellement, y compris celles qui n'ont jamais été documentées.
6.4.2 : détection et prévention automatisées pour les applications exposées au public
Il est utile de recalibrer vos processus si vous vous basez sur d'anciennes directives. Selon le Conseil, après le 31 mars 2025, la norme 6.4.2 devient l'exigence en vigueur, tandis que la 6.4.1 est remplacée et doit être signalée comme non applicable.. L'option de révision manuelle des vulnérabilités est supprimée. Les applications web exposées au public doivent disposer d'une solution technique automatisée qui détecte et prévient en continu les attaques web.
Salt répond à cette exigence sur l'ensemble de votre surface d'attaque API. Salt Protect détecte les attaques spécifiques aux API lors de l'exécution et permet un blocage ciblé. Les règles gérées par Salt pour AWS WAF vont plus loin en bloquant directement au sein d'AWS WAF les attaques par force brute sur les identifiants, les SSRF, la pollution de prototype, les requêtes GraphQL excessives et les anomalies JWT. Pour les applications pilotées par API, il s'agit d'une réponse nettement plus robuste à la norme 6.4.2 qu'un ensemble de règles WAF généraliste, car ces derniers n'ont pas été conçus en tenant compte des classes d'attaques visant les API.
La couverture des classes d'attaques web non liées aux API est assurée par vos contrôles web plus larges et, comme toujours, votre évaluateur confirmera leur adéquation avec votre architecture.
6.4.3 et 11.6.1 : scripts des pages de paiement
Ces exigences sont également entrées en vigueur le 31 mars 2025 et constituent la partie de la version 4.x la plus souvent sous-estimée par les commerçants en ligne. Le Conseil a publié des directives dédiées sur la sécurité des pages de paiement et l'e-skimming en mars 2025.
6.4.3 exige que les scripts chargés et exécutés sur la page de paiement soient gérés : chacun doit être autorisé, son intégrité garantie, et un inventaire doit être tenu à jour avec une justification commerciale ou technique écrite. 11.6.1 exige un mécanisme capable de détecter et d'alerter en cas de modification non autorisée des en-têtes HTTP liés à la sécurité et du contenu de la page de paiement tel qu'il est reçu par le navigateur du consommateur.
Il s'agit de contrôles au niveau du navigateur, et leur respect nécessite des outils dédiés à l'intégrité des scripts qui observent la page telle que le navigateur du consommateur la reçoit. Salt opère sur la couche inférieure, là où résident réellement les données des titulaires de carte, et les deux solutions se complètent parfaitement.
Un contrôle d'intégrité des scripts vous indique qu'un script sur votre page de paiement a été modifié. Salt vous indique ce que ce changement peut atteindre : quelles API le script appelle, si ces API traitent des données de titulaires de carte, si leur posture d'authentification est solide et si leur comportement à l'exécution a changé après la modification. L'e-skimming n'a de conséquences que grâce aux données situées à l'autre extrémité de l'appel, et cette extrémité est le domaine de Salt. Les commerçants utilisant les deux contrôles bénéficient d'une visibilité complète, de la page de paiement au script, puis à l'API et enfin aux données des titulaires de carte.
Une précision s'impose, car elle est source de confusion : les révisions de 2025 du SAQ A ont supprimé les points 6.4.3 et 11.6.1 de ce questionnaire et ont ajouté un critère d'éligibilité exigeant que le commerçant confirme que son site n'est pas vulnérable aux attaques par script affectant ses systèmes de commerce électronique. Ces exigences n'ayant pas été supprimées de la norme elle-même, il ne s'agit pas d'une exemption générale concernant la sécurité des scripts.
6.5.1 et 6.5.2 : gestion sécurisée des changements
La section 6.5.1 exige que les changements en production soient gérés avec une justification documentée, une analyse de l'impact sur la sécurité, une approbation, des tests et une procédure de retour arrière sécurisée. La section 6.5.2 exige une confirmation, après tout changement significatif, que les contrôles PCI applicables sont toujours en place et que la documentation est mise à jour.
Salt Code teste le code par rapport à la politique avant le déploiement. La gouvernance de la posture détecte les dérives par la suite et exporte les preuves. La connexion et la découverte continue révèlent les API nouvellement exposées introduites par un changement. Ensemble, ils vous fournissent une réponse documentée à la question « ce changement a-t-il affecté notre posture de sécurité ? », ce qui est la question réelle posée par la section 6.5.2, et une question difficile à résoudre de manière crédible sans surveillance continue.
Votre flux de travail de gestion des changements fournit l'approbation, la justification commerciale et la procédure de retour arrière. Salt fournit les preuves de sécurité dont ce flux de travail a besoin.
4.2.1 : données de titulaires de carte en transit
La section 4.2.1 exige une cryptographie forte et des protocoles de sécurité pour protéger les données des titulaires de carte transmises sur des réseaux ouverts et publics.
La contribution de Salt ici consiste à trouver les chemins que vous ignoriez. La découverte de données sensibles classifie les API transportant des données PCI, cartographie leurs chemins d'accès, signale les données sensibles accessibles sur des points de terminaison publics ou non authentifiés, et valide la protection de la couche de transport. C'est ainsi que les équipes trouvent le chemin de transmission faiblement protégé que personne n'a documenté, et Salt Code peut imposer des modèles d'API sécurisés avant que le prochain ne soit déployé.
Une fois que Salt révèle une protection de transport faible ou manquante, votre équipe de plateforme effectue le changement de configuration TLS et de certificat.
12.5.1 et 12.5.2 : périmètre et inventaire
La section 12.5.1 exige un inventaire à jour des composants système inclus dans le périmètre. La section 12.5.2 exige que vous documentiez et confirmiez le périmètre PCI au moins annuellement et après tout changement significatif, y compris les flux de données de paiement.
Le périmètre est là où la prolifération des API fait ses véritables dégâts. Un point de terminaison non documenté traitant des données de carte, accessible depuis Internet, est un échec de définition de périmètre avant d'être une faille de sécurité, et c'est exactement le genre de chose qu'une revue ponctuelle ne détecte pas.
Surface, Connect, la découverte continue et la cartographie des données sensibles vous fournissent une vue d'ensemble des API exposées et internes, des points de terminaison fantômes et zombies, de la propriété, de la posture et des flux de données des titulaires de carte. Salt couvre en profondeur la partie API et agentique de votre inventaire inclus dans le périmètre ; votre documentation de périmètre CDE intègre le reste de l'environnement ainsi que les diagrammes de réseau et de flux de données exigés par PCI.
Comment Salt s'intègre à vos autres contrôles PCI
La norme PCI DSS est un cadre couvrant les personnes, les processus et la technologie, et un programme solide superpose les contrôles plutôt que de s'appuyer sur un seul d'entre eux. Salt constitue la couche API et agentique de ce programme. Voici comment il se situe par rapport au reste :
- Votre évaluateur détermine la conformité. Salt fournit les contrôles techniques et les preuves continues qui permettent au processus d'évaluation de se dérouler sans encombre.
- Vos analyses ASV et de vulnérabilités répondent aux exigences d'analyse de la section 11.3. La posture et les résultats d'analyse de code de Salt vous aident à prioriser les mesures correctives en tenant compte de l'exposition et du contexte des données de titulaires de carte, des éléments absents de ces analyses classiques.
- Vos systèmes d'identité gèrent l'authentification, le MFA et les accès privilégiés. Salt identifie les lacunes de posture en matière d'authentification et d'autorisation au sein de vos API et détecte les utilisations abusives d'identifiants techniquement valides.
- Outils dédiés à l'intégrité des scripts couvrent les sections 6.4.3 et 11.6.1 au niveau du navigateur. Salt prend en charge les API et les données de titulaires de carte auxquelles ces scripts accèdent.
- Votre programme de gestion des correctifs et des vulnérabilités suit les sources de vulnérabilités reconnues par l'industrie. Salt y ajoute les risques au niveau de la couche API qui n'apparaissent jamais dans les flux CVE.
- Votre plateforme de journalisation assure le respect de l'exigence 10 sur tous les systèmes concernés. La télémétrie en temps réel et les chronologies d'attaques de Salt lui fournissent les preuves de sécurité API qui lui manqueraient autrement, via vos flux de travail SIEM et SOAR.
- Votre plateforme de données applique la conservation et la suppression sécurisée conformément à la section 3.2.1. Salt vous montre où les données réglementées circulent réellement via les API, ce qui correspond souvent à la partie que personne n'a cartographiée.
Passer à l'étape suivante
Les API occupent une place plus importante dans la norme PCI DSS v4.x que dans toute version précédente. Les exigences les plus critiques sont celles que les outils de sécurité applicative traditionnels gèrent le moins bien : abus de logique métier, manipulation du contrôle d'accès, inventaire continuellement à jour et circulation de données de titulaires de carte via des interfaces non documentées. Ce sont précisément les problèmes pour lesquels Salt a été conçu, couvrant la découverte, le code, la configuration, l'exposition des données, le comportement à l'exécution et l'application des règles, avec des preuves techniques continues plutôt que des captures d'écran annuelles.
Si vous souhaitez identifier quelles API traitent des données de titulaires de carte et où se situent vos lacunes techniques, demandez une évaluation de la surface d'attaque API, ou demandez une démonstration et notre équipe passera en revue votre périmètre PCI avec vous.
La norme PCI DSS v4.0.1 est la norme en vigueur depuis septembre 2026. Salt fournit des contrôles techniques, une visibilité et des preuves qui soutiennent les exigences PCI DSS. Salt ne certifie pas une entité comme étant conforme à la norme PCI. L'applicabilité et la suffisance dépendent de votre architecture et doivent être validées par votre acquéreur, votre marque de paiement, votre ISA ou votre QSA.
Publié initialement par Amanda Fitzsimmons le 21 juin 2024. Mis à jour le 18 septembre 2026 par Nika Engberg, directrice juridique.