Définition de la sécurité côté client
Dans le contexte de la sécurité web, la « sécurité côté client » protège vos utilisateurs contre l'injection de code malveillant dans leur navigateur depuis votre site web. Ces injections de code malveillant comprennent les skimmers de cartes bancaires, les superpositions visuelles qui redirigent les utilisateurs vers des pages de phishing, ou des schémas de fraude sophistiqués comme la fraude aux liens d'affiliation.
Les sites web ne servent pas intentionnellement du code malveillant à leurs utilisateurs. Mais les « attaques côté client » injectent du code via des points d'entrée cachés : les scripts tiers provenant d'outils intégrés à votre site (balises analytics, bibliothèques de polices, outils open source, plugins) et les scripts propriétaires dans lesquels les attaquants placent du code obfusqué que votre équipe de sécurité ne détecte pas.
La « sécurité côté client » selon les contextes
| Vecteur de sécurité côté client | Objectif | Protège contre | Utilisé par |
|---|---|---|---|
| 1. Installation d'un extrait de code sur votre propre site web | Protéger les utilisateurs contre des attaques comme le web skimming. Se conformer à des référentiels comme PCI DSS ou le RGPD. | Les injections de code servies aux navigateurs des utilisateurs depuis votre site web. | Les sites e-commerce, les plateformes SaaS et toute entreprise qui traite des paiements ou collecte des données personnelles sur le web. |
| 2. Installation d'un logiciel sur le navigateur de l'utilisateur final (extension de navigateur) | Orienté client : Avertit les consommateurs des sites de phishing ou des téléchargements dangereux. Orienté employé : Applique les politiques de prévention des pertes de données et contrôle ce que les employés peuvent partager via le navigateur. | Les menaces rencontrées par l'utilisateur lors de sa navigation. Les fuites de données non autorisées depuis le navigateur. | Les éditeurs de sécurité grand public proposent des extensions de navigation sécurisée. Les entreprises les déploient pour contrôler l'activité des employés dans le navigateur et prévenir les fuites de données. |
| 3. Installation d'un logiciel sur l'appareil de l'utilisateur final | Orienté client : Sécurise les sessions en détectant les malwares présents sur l'appareil du client. Orienté employé : Surveille les appareils gérés par l'entreprise à la recherche de malwares. | Les keyloggers, chevaux de Troie et autres malwares s'exécutant localement sur l'appareil de l'utilisateur. | Les banques proposent à leurs clients une protection endpoint gratuite pour sécuriser les sessions de banque en ligne contre les malwares locaux. Les employeurs déploient des agents EDR sur les appareils de l'entreprise pour détecter les menaces. |
Lors des conférences de cybersécurité, évoquer la « sécurité côté client » suscite des perceptions différentes selon le domaine de sécurité dans lequel chaque personne travaille. Le dénominateur commun est que la « sécurité côté client » se concentre sur la surveillance d'un environnement qui s'exécute sur l'appareil de l'utilisateur final — et non sur vos propres serveurs, API ou trafic réseau.
cside opère dans le premier vecteur de sécurité côté client du tableau ci-dessus. Les marchands et les plateformes logicielles implémentent un extrait de code sur leur site web, ce qui nous permet de surveiller l'exécution dans le navigateur lors des sessions des visiteurs. Pour simplifier, cela fonctionne de manière similaire aux outils d'analytics que vous installez sur votre site. Mais nous surveillons les signes de failles de sécurité et de fraude, plutôt qu'à des fins marketing.
Pourquoi sécuriser le côté client ?
Chez cside, notre équipe est profondément engagée dans la sécurité côté client (le nom de l'entreprise est dérivé de client-side). L'entreprise a été fondée parce que nous avons constaté que les outils de sécurité web traditionnels offraient une visibilité limitée sur l'exécution dans le navigateur des utilisateurs, laissant un angle mort considérable. En tant que co-présidents de la communauté W3C Anti-Fraud Browser Security, notre mission est de protéger les consommateurs et les marchands contre la fraude sur le web.
Beaucoup d'attention est portée à la sécurisation de la chaîne d'approvisionnement. Les développeurs analysent les packages NPM. L'infrastructure est verrouillée. Les pare-feux et les WAF sont considérés comme des bases. Et la sécurité cloud est devenue une catégorie à part entière. Mais l'une des surfaces d'attaque les plus importantes et à la croissance la plus rapide est encore négligée : le côté client. Mastercard a souligné que près de trois quarts des violations publiquement divulguées impliquent du skimming numérique.
La sécurité côté client couvre tout ce qui s'exécute dans le navigateur de vos utilisateurs. Cela inclut le JavaScript tiers, les pixels, les iFrames, les formulaires, les SDK et tout code récupéré et exécuté après le chargement de la page. Cette partie de la pile est presque toujours ignorée lors des audits, pourtant elle est responsable de certaines des attaques les plus dévastatrices.
Les scripts tiers sont chargés directement dans le navigateur et exécutés avec un accès complet au DOM. Ces scripts peuvent analyser les formulaires, enregistrer le comportement des utilisateurs, modifier le contenu de la page et exfiltrer des données sans jamais toucher votre serveur. C'est là que la protection côté client est la plus importante — non seulement surveiller l'origine des scripts, mais aussi ce qu'ils font réellement.
Et les choses tournent mal. Souvent. L'attaque de la chaîne d'approvisionnement Polyfill a ciblé plus de 490 000 sites web en injectant du code malveillant dans une bibliothèque open source auparavant de confiance. Avant cela, Kaiser Permanente a exposé les données de 13,4 millions de patients en raison de scripts côté client intégrés envoyant des données vers des destinations non autorisées.
Si vous ne faites pas d'analyse active côté client, vous ne protégez pas vos utilisateurs. Car lorsque quelque chose tourne mal, la responsabilité vous incombe, pas nécessairement au fournisseur qui a servi le script.
La sécurité côté client n'est plus optionnelle. Si votre site traite des paiements, collecte des informations personnelles ou demande aux utilisateurs de se connecter, vous êtes une cible. Et le navigateur est l'endroit où ces attaques se produisent.
Menaces et types d'attaques côté client
1. Contrôle d'accès côté client défaillant
Le contrôle d'accès est souvent perçu comme une préoccupation côté serveur. Mais les défaillances du contrôle d'accès côté client sont bien réelles, et elles sont souvent négligées. Le JavaScript dans le navigateur peut être utilisé pour manipuler le DOM et accéder à des données ou des fonctions qui n'étaient pas censées être exposées. Si un script n'est pas correctement isolé (ou si des tokens sont laissés en mémoire, par exemple), il devient facile pour les attaquants d'obtenir un accès sans déclencher les vérifications backend.
C'est l'un des types de vulnérabilités côté client les plus silencieux. Et comme cela se passe dans le navigateur, la journalisation traditionnelle ne le détecte pas.
2. Cross-Site Scripting (XSS) basé sur le DOM
Le XSS basé sur le DOM est une attaque courante et persistante. Elle se produit lorsque JavaScript lit une entrée non fiable (comme des paramètres d'URL par exemple) et la réécrit dans la page sans assainissement. Cette forme d'injection ne repose pas sur les réponses du serveur, ce qui la rend difficile à détecter avec les pare-feux d'applications web traditionnels.
Les outils d'analyse côté client sont souvent le seul moyen de détecter cela en temps réel. Sans eux, les attaquants peuvent injecter des scripts arbitraires et compromettre entièrement la session navigateur de l'utilisateur.
3. Domaines expirés
Lorsqu'un domaine référencé dans votre code expire, n'importe qui peut l'acheter. Si votre JavaScript pointe encore vers ce domaine pour un script, une feuille de style, ou même un lien codé en dur, le nouveau propriétaire contrôle ce qui est servi. Les attaquants recherchent activement ces opportunités car le domaine entretient déjà une relation de confiance avec votre site et vos utilisateurs.
Notre équipe de recherche en sécurité a découvert une vulnérabilité liée à un domaine expiré sur le site d'Oracle, où un fichier JavaScript référençait un domaine qui avait expiré et était disponible à l'achat.
4. Fuite de données sensibles
La fuite de données côté client est l'un des risques les plus coûteux en matière de sécurité JavaScript. Elle se produit lorsque des scripts collectent des informations sensibles (comme des noms, des e-mails ou des coordonnées bancaires par exemple) et les transmettent à des domaines externes. Parfois c'est intentionnel. Souvent, ça ne l'est pas.
Lorsque Kaiser Permanente a exposé plus de 13,4 millions de dossiers, c'est parce que du code côté client intégré envoyait des données à des tiers sans le consentement des utilisateurs. Une surveillance côté client aurait signalé les tentatives d'exfiltration avant que les données ne quittent la page.
5. Composants vulnérables et obsolètes
Les bibliothèques JavaScript obsolètes sont l'un des points d'entrée les plus exploités dans les attaques côté client. Elles sont souvent récupérées depuis des CDN ou des fournisseurs tiers et ne sont jamais réexaminées. Si cette bibliothèque présente un CVE connu et que votre site la charge, vous êtes exposé.
C'est précisément ce qui a rendu l'attaque Polyfill si efficace. Un script largement utilisé a été compromis à la source, et la plupart des entreprises ne savaient même pas qu'elles le chargeaient. La protection côté client doit inclure le suivi des versions des bibliothèques pour garder une longueur d'avance sur ces types de risques.
6. Absence de contrôle des origines tierces
La plupart des attaques côté client ne partent pas de votre code. Elles proviennent d'une origine tierce à laquelle vous avez fait confiance sans vérification. Ces scripts se chargent avec toutes les permissions dans votre environnement navigateur, leur donnant accès à tout ce que l'utilisateur voit et fait.
Lorsque du JavaScript tiers est autorisé à s'exécuter librement, vous perdez le contrôle. À moins d'utiliser une Content Security Policy (CSP) stricte et une analyse côté client en temps réel, vous n'avez aucune idée de ce que fait ce script. Sans l'analyse côté client en temps réel, une CSP est le plus souvent insuffisante pour l'arrêter.
La compromission de la chaîne d'approvisionnement du SDK web AppsFlyer en est un exemple récent. Des attaquants ont détourné le DNS d'un SDK marketing de confiance et ont servi une charge utile de vol de cryptomonnaies à des milliers de sites qui ignoraient que leurs scripts avaient changé.
7. Dérive JavaScript
La dérive JavaScript se produit lorsque le contenu d'un script change au fil du temps, sans que personne ne s'en aperçoive. Un script qui était sûr la semaine dernière peut maintenant se comporter de manière totalement différente, surtout s'il est servi depuis une source distante. Certains attaquants exploitent cela en introduisant progressivement un comportement malveillant pour éviter la détection.
Chez cside, nous ne nous contentons pas de suivre l'URL. Nous enregistrons et analysons la charge utile complète de chaque script, à chaque fois. C'est ainsi que nous détectons les nouvelles vulnérabilités côté client avant qu'elles ne deviennent des violations.
8. Données sensibles stockées côté client
Lorsque JavaScript stocke des données dans localStorage, sessionStorage ou des cookies, ces données sont accessibles par n'importe quel script sur la page, y compris les scripts tiers. Cela crée une surface d'attaque massive pour le détournement de session, le vol de tokens et les fuites inter-sites.
Si vous stockez quoi que ce soit de sensible côté client (voir les exemples ci-dessus), vous avez besoin d'une portée stricte, d'une logique d'expiration et d'une surveillance en temps réel pour détecter les abus. La plupart des sites web ignorent complètement cela.
9. Défaillances de journalisation et de surveillance côté client
On ne peut pas sécuriser ce qu'on n'observe pas. La plupart des organisations traitent encore la journalisation comme une responsabilité côté serveur. Mais lorsque des scripts s'exécutent dans le navigateur et que des attaques se produisent en temps réel, vous avez également besoin d'une surveillance côté client.
Cela inclut la visibilité sur les interactions avec les formulaires, le comportement des scripts, les requêtes sortantes inattendues et les erreurs JavaScript. Sans cela, vous naviguez à l'aveugle.
10. Non-utilisation des contrôles de sécurité natifs du navigateur
Des défenses natives au navigateur existent. Mais de nombreux sites les ignorent. La Content Security Policy (CSP), la Subresource Integrity (SRI), le sandboxing des iframes... ce sont autant de moyens de réduire les risques liés aux scripts malveillants et au contenu injecté. Mais la plupart des équipes les configurent mal ou les désactivent entièrement pour éviter de casser des fonctionnalités.
Si vous voulez une véritable sécurité côté client, commencez par appliquer les contrôles que le navigateur prend déjà en charge.
11. Inclusion de logique propriétaire côté client
Votre frontend est visible par tout le monde. Cela inclut la logique métier, les algorithmes de tarification, les règles de routage internes et tout ce que vous déployez pour être chargé dans le navigateur. Il est courant de trouver des processus sensibles codés en dur dans du JavaScript, où ils peuvent être rétro-ingénierés ou détournés.
Ce n'est pas seulement un risque pour la vie privée, c'est aussi un risque pour la propriété intellectuelle. Si cela s'exécute côté client, c'est exposé. Et si c'est exposé, cela doit être surveillé.
« Les développeurs disent souvent "ne jamais faire confiance au côté client" — et pourtant, nous injectons régulièrement des dizaines de requêtes côté client vers des tiers. La réalité, c'est que le côté client est devenu la principale surface des attaques silencieuses. C'est là que les vulnérabilités prospèrent, précisément parce qu'il est si facile d'échapper à la détection. »
— Simon Wijckmans, CEO de Cside
Pourquoi les détections côté client ne peuvent pas reposer uniquement sur des flux de menaces
La plupart des outils qui prétendent offrir une protection côté client s'appuient sur deux choses :
- Des listes d'autorisation
- Des flux de renseignements sur les menaces précompilés.
Les attaquants conçoivent désormais des charges utiles côté client pour contourner ces méthodes de détection. Ils modifient dynamiquement le contenu du script. Ils ciblent uniquement des sites web spécifiques. Ils ne servent du code malveillant qu'une seule fois.
Si votre méthode de détection ne surveille que les domaines connus ou les signatures d'attaques passées, vous ne verrez pas ce qui arrive. Le script est peut-être déjà compromis, mais votre outil ne le sait pas car personne ne l'a encore signalé.
C'est pourquoi l'inspection des charges utiles JavaScript en temps réel est la seule approche fiable pour l'analyse côté client.
Référentiels de conformité imposant des contrôles de sécurité côté client
PCI DSS 4.0.1
PCI DSS 4.0.1 exige que les entreprises surveillent et autorisent tous les scripts côté client. Les exigences 6.4.3 et 11.6.1 sont devenues obligatoires en mars 2025 et sont désormais activement appliquées. Si votre site traite des paiements, cela implique une visibilité en temps réel sur ce qui s'exécute dans le navigateur — pas seulement une liste statique de domaines approuvés.
Nous avons rédigé un guide sur les mécanismes côté client précis qui satisfont à cette exigence.
RGPD, CCPA et autres référentiels liés à la vie privée
Si des données personnelles sont collectées ou transmises via des scripts tiers sans consentement ni supervision, vous êtes exposé. Peu importe que le script provienne d'un fournisseur de confiance. Vous en êtes quand même responsable.
Les articles 25, 28, 30 et 32 du RGPD, entre autres, définissent la nécessité de contrôles côté client tels que la visibilité sur l'activité de collecte des tiers et les mesures de protection contre les fuites de données.
HIPAA, SOC 2 et DORA vont dans la même direction. La protection côté client n'est plus seulement une question de sécurité. C'est aussi une question de conformité. Et les contrôles se renforcent.
Différentes approches de la sécurité côté client
1. Les Content Security Policies (CSP)
Les CSP sont des contrôles au niveau du navigateur qui restreignent les domaines autorisés à servir des scripts sur vos pages. C'est un bon point de départ, mais elles présentent de vraies lacunes :
- Elles valident uniquement l'origine d'un script, pas ce qu'il fait une fois exécuté.
- Elles ne peuvent pas détecter les scripts qui modifient leur comportement en fonction de l'utilisateur, de la session ou de la géographie.
- Les violations de CSP génèrent des erreurs dans la console qui poussent les développeurs à assouplir les politiques ou à les désactiver entièrement.
L'attaque de la chaîne d'approvisionnement Polyfill a montré exactement ce qui se passe lorsqu'on fait confiance à une URL source qui est compromise. Le domaine était autorisé par la CSP, et le code malveillant s'est exécuté librement.
2. Les approches par crawler ou « scanner »
Les outils de crawling visitent votre site selon un calendrier et vérifient la présence de scripts malveillants. Le problème est que la détection est retardée et facile à contourner :
- Les attaquants peuvent identifier les crawlers et leur servir du code propre tout en délivrant des charges utiles malveillantes aux vrais utilisateurs.
- La plupart des crawlers n'échantillonnent qu'une fraction du trafic, ce qui permet aux attaques ciblant des utilisateurs ou des régions spécifiques de passer entre les mailles du filet.
- Ils ne voient jamais le script réel que le navigateur d'un vrai utilisateur reçoit lors d'une session en direct.
3. La détection côté client basée sur JavaScript
Les outils basés sur JavaScript s'exécutent dans le navigateur pour observer l'activité des scripts en temps réel. Mais ils présentent des faiblesses importantes :
- Ils fonctionnent comme des pièges, mais comme ils vivent dans le même environnement que les scripts qu'ils surveillent, les attaquants peuvent les détecter et les éviter.
- Ils n'ont pas de contexte historique, ils ne peuvent donc pas suivre l'évolution d'un script dans le temps ni soutenir une investigation forensique après un incident.
Avec des réglementations comme PCI DSS qui exigent désormais des contrôles de scripts côté client, ces approches sont souvent utilisées pour cocher rapidement la case de conformité. Mais elles n'offrent pas une protection réelle. Elles laissent les entreprises exposées à des attaques qui s'adaptent plus vite que ces outils ne peuvent suivre.
Lisez ici un guide de comparaison et de sélection approfondi.
Comment cside sécurise le côté client
Nous avons conçu cside pour fournir une surveillance côté client en temps réel et une protection contre les menaces JavaScript sans ralentir votre site.
- Inspection des charges utiles : Nous capturons et comparons les charges utiles complètes des scripts à chaque requête de récupération et de chargement, pas seulement le domaine ou le hash.
- Gestion des scripts tiers : Surveillez, versionnez et verrouillez les scripts tiers pour qu'ils ne changent pas silencieusement en production.
- Détection des expositions de données : Nous détectons les données qui fuient vers des points de terminaison inattendus avant que cela ne devienne un problème de conformité.
- Préparation à la conformité : Que vous vous prépariez à PCI DSS 4.0 ou que vous gériez les risques liés au RGPD, nous vous aidons à rester prêt pour les audits.
