PCI DSS 4.0 est là. D'ici mars 2025, il impose que les portails de paiement disposent d'un moyen d'autoriser chaque script sur les pages de paiement. Les sites web doivent tenir un inventaire de tous les scripts (sur ces portails de paiement au moins) et garantir leur intégrité. Vous devez désormais détecter et répondre aux modifications non autorisées sur les pages de paiement, y compris les changements d'en-têtes HTTP et de contenu de page. Les organisations doivent vérifier ces configurations au moins une fois tous les sept jours ou selon leur évaluation d'analyse de risque.
Consultez les exigences complètes ici.
Un autre point important à retenir est que PCI DSS 4.0 encourage désormais un passage des audits annuels à une surveillance continue de la sécurité, impliquant des révisions et mises à jour régulières des composants système et des logiciels.
Enfin !
À l'heure actuelle, seuls les portails de paiement sont tenus de disposer d'un système pour contrôler les JavaScript tiers. C'est pourquoi bon nombre de nos concurrents (lisez ce que nous pensons d'eux ici) limitent leurs services à quelques pages seulement. Certains vont même jusqu'à échantillonner les sessions, de sorte que seulement 10 % des sessions sont protégées.
Mais c'est chercher les ennuis.
Pourquoi vous devriez protéger toutes les pages
Il existe toujours un risque de violation de données si vous ne sécurisez pas toutes les pages.
Des acteurs malveillants pourraient utiliser des scripts compromis sur d'autres parties de votre site pour détourner des sessions utilisateur. Cela leur permettrait d'usurper l'identité d'utilisateurs légitimes et d'effectuer des actions non autorisées, pouvant même contourner certaines formes d'authentification à deux facteurs. Cela pourrait potentiellement déjouer votre protection des scripts tiers sur les portails de paiement.
Un autre domaine que vous laisseriez exposé au risque est celui des vulnérabilités de type Cross-site scripting (XSS). Elles permettent aux attaquants d'injecter des scripts malveillants dans des pages web consultées par d'autres utilisateurs. Si seul le portail de paiement est protégé, d'autres pages pourraient être exploitées pour exécuter des attaques XSS, compromettant quand même les données et la vie privée des utilisateurs.
Dans certains cas, les attaques de la chaîne d'approvisionnement ne sont pas totalement bloquées non plus. Les scripts tiers constituent un vecteur courant pour ce type d'attaques. Si des attaquants compromettent un fournisseur ou un script utilisé sur l'ensemble de votre site, concentrer les protections uniquement sur le portail de paiement n'empêchera pas l'exploitation via d'autres intégrations tierces.
Les vulnérabilités d'exécution de code à distance (RCE) et d'injection de commandes représentent des risques de sécurité importants qui soulignent davantage la nécessité de sécuriser toutes les pages, et pas seulement les zones critiques comme les portails de paiement. Le RCE permet aux attaquants d'exécuter du code arbitraire sur votre serveur, pouvant mener à une compromission totale du système. Cela peut se produire via une gestion non sécurisée des entrées utilisateur, comme l'évaluation de code téléchargé par des utilisateurs ou injecté via des champs de formulaire.
Les vulnérabilités d'injection de commandes surviennent lorsque des entrées utilisateur non sécurisées sont exécutées comme des commandes système, notamment via des entrées JavaScript mal assainies. Cela peut permettre aux attaquants de manipuler les actions du serveur ou d'accéder aux bases de données backend, entraînant des modifications non autorisées ou le vol de données.
Enfin, l'ingénierie sociale et le phishing constituent une menace bien réelle. Des attaquants pourraient modifier le contenu ou rediriger les utilisateurs vers des sites malveillants, les incitant à fournir des informations sensibles.
Autres vulnérabilités
Même si vos portails de paiement sont protégés et que la protection fonctionne, vous restez exposé au risque que des scripts sur d'autres pages soient compromis, comme nous l'avons établi.
Si cela se produit, vous courez toujours le risque de perdre la confiance des utilisateurs et de faire face à des implications juridiques ou réglementaires, notamment en ce qui concerne les lois sur la protection des données comme le RGPD ou le CCPA. Les dommages en termes d'amendes ou d'atteinte à la réputation sont difficiles à quantifier. Ils sont pourtant bien réels.
Alors faites-le bien, dès maintenant
Tout comme les règles PCI DSS 4.0, nous encourageons également tout propriétaire de site à adopter une surveillance continue de la sécurité. Et j'espère que nous avons démontré que le faire sur toutes les pages est la meilleure approche.
Le niveau gratuit de cside rend votre site conforme à PCI DSS en ce qui concerne les scripts tiers, et il fonctionne sur toutes les pages. Notre approche est toutefois différente de celle de la concurrence. Notre script réécrit les sources des autres scripts de votre site pour les proxifier via cside et effectuer certaines détections côté navigateur. cside s'insère ainsi dans le flux de la requête entre l'utilisateur et le script tiers, sans latence supplémentaire, et améliore même parfois les performances grâce à la mise en cache des scripts statiques.
Cela permet une visibilité totale sur les scripts servis, sur 100 % des sessions et sur toutes les pages. Vous protégeant, vous et vos utilisateurs.
Si vous souhaitez en savoir plus sur ce qui distingue notre approche, rendez-vous ici.
