cside offre la solution de sécurité côté client la plus complète disponible aujourd'hui grâce à son approche multicouche avec des capacités de détection uniques. La plupart des autres solutions du marché reposent sur un seul mécanisme, tandis que cside en utilise plusieurs pour offrir la plus grande couverture.
TLDR :
- cside propose aujourd'hui la solution la plus complète du marché en combinant :
- Dans les détections de comportement des scripts de navigateur
- En dehors de l'analyse du contenu du script et du site lui-même
- Détections multi-moteurs, y compris analyse basée sur l'IA
- cside dispose également de nombreux ingénieurs habitués à évoluer au « pays de l'imparfait » ayant travaillé sur divers projets classifiés en dehors des spécifications technologiques prévues.
- L’équipe partage activement des informations approfondies en matière de sécurité sur les attaques nouvellement détectées lors de réunions communautaires spécialisées du secteur non commercial.
- L'équipe cside contribue activement aux comités standards comme le w3c et l'IETF
Qu’est-ce que la sécurité côté client ?
Vidéo expliquant la sécurité côté client
La sécurité côté client signifie approfondir les comportements d’une application Web côté client, donc dans le navigateur d’un utilisateur.
Le fonctionnement d'un navigateur est plutôt simple :
- Le navigateur reçoit une réponse HTML du serveur Web. Ce fichier HTML indique au navigateur les autres ressources dont il doit disposer, comme les polices, les feuilles de style mais aussi les JavaScripts pour rendre le site Web réactif.
- Le navigateur récupère ces ressources. Certaines de ces ressources proviendront du serveur Web contrôlé par le site Web (c'est ce qu'on appelle « première partie »), mais d'autres proviendront des serveurs d'autres sociétés. Polices, outils marketing, publicités, outils de suivi… Ce sont des actifs tiers.
- Ces actifs peuvent à eux seuls récupérer un autre actif sur un autre serveur. Cela crée donc un arbre de dépendances potentiellement infini.
Le gros problème est que ces actifs tiers font l’objet d’une activité entre le navigateur de l’utilisateur et le serveur de l’autre société.
Par défaut, le propriétaire du site Web ne sait pas ce que font ces scripts sur un site. Mais ils sont considérés comme leur responsabilité, car ils ont été placés là comme leurs dépendances.
Les JavaScripts sur une page Web sont incroyablement puissants. Un script peut écouter les événements de frappe, exfiltrer des données vers des points de terminaison, exploiter votre puissance de calcul pour extraire des crypto-monnaies, superposer des objets iframe pour intercepter les informations de carte de crédit ou tromper les utilisateurs en leur faisant authentifier leur portefeuille crypto pour un mauvais acteur, voler des informations sensibles présentées sur la page Web…
Les mauvais acteurs disposent de nombreuses façons d’injecter de tels scripts. Pour acheter des domaines expirés, infiltrer des projets open source ou simplement obtenir les informations d'identification d'un utilisateur de Google Tag Manager.
Ces types d'attaques existent depuis longtemps, remontant à l'époque où JavaScript était limité en fonctionnalités et où nous devions installer FlashPlayer et Microsoft Silverlight pour avoir des expériences Web réactives.
Mais en 2008, JavaScript est devenu beaucoup plus puissant avec la sortie de nouvelles API de navigateur et d'un moteur JavaScript plus puissant, le V8 de Google. Résultat : le vecteur d'attaque a augmenté en taille au même rythme que les nouvelles capacités de JavaScript. Avec des attaques à grande échelle qui se produisent régulièrement, mais l’intérêt des médias culmine vers 2017-2020.
Des exemples de cette méthode d'attaque sont les Attaque CoinMarketCap (2025), L'attaque Bybit (2025), Attaque Polyfill (2024) mais aussi des grands plus âgés comme L'attaque de British Airways (2018).
Nous avons un article de blog complet sur ce qu'est la sécurité côté client ici.
Qu’est-ce qui constitue une solution de sécurité complète côté client ?
Le fait est que les navigateurs n’ont jamais été conçus pour assurer la sécurité côté client. Lorsque JavaScript a été ajouté aux navigateurs, tout comme la plupart des progrès réalisés dans le monde technologique, la sécurité était une réflexion secondaire.
La triste réalité est qu’aujourd’hui, après 30 ans d’ajout de JavaScript aux navigateurs à grande échelle, la sécurité côté client via JavaScript reste un hack. Une solution qui, même avec les meilleures intentions les plus lointaines, n’est pas totalement étanche.
Les navigateurs sont un terrain de jeu équitable. Contrairement à un système d'exploitation comme Windows, les fournisseurs de sécurité n'ont aucun effet de levier ni aucun contrôle supplémentaire. Contrairement à MacOS, les scripts ne sont pas certifiés. Cela crée une surface d’attaque facilement exploitable et difficile à protéger.
Dans le cadre de la sécurité côté client une solution complète :
- Combine des approches pour rendre plus difficile le contournement de l'ensemble de la plate-forme.
- Est conscient de chacune des forces et faiblesses de chaque approche et les ajuste en fonction du modèle de menace d’un site Web.
- Détecte les signaux au moment de l'exécution.
- Analyse le contenu du script en dehors de l'environnement du navigateur.
- Analyse les métadonnées sources lorsque les scripts sont servis.
- Crée un histogramme caractérisant le script à chaque récupération pour détecter les modifications malveillantes.
Pourquoi cside est spécialement configuré pour la sécurité côté client
cside a été fondée par une équipe possédant une expérience unique dans le domaine des navigateurs et de la sécurité côté client. L'équipe fondatrice a auparavant occupé des postes chez Cloudflare et Vercel.
Cloudflare se situe à la frontière de la sécurité Web conviviale. Agissant comme premier point de contact pour environ 20 % de l’Internet public. Chez Cloudflare, divers membres de l'équipe de cside ont travaillé sur le pare-feu, la détection des robots et leur outil de dépendance de sécurité côté client, Page Shield.
Chez Vercel, l'équipe a également travaillé sur les éléments fondamentaux de la pile de sécurité Web et davantage de visibilité et d'expérience de niche ont été construites avec les frameworks JavaScript et V8.
L'équipe cside compte également un certain nombre d'ingénieurs qui ont travaillé sur les composants internes du navigateur :
- Contributeurs au projet open source de Servomoteur. Servo est un moteur de navigateur basé sur Rust offrant une alternative à Chromium mais construit sur Rust.
- Dans une vie antérieure, l'équipe a également contribué à des projets tels que TailwindCSS et Bootstrap. Création de bibliothèques comme Tailwind OKLCH et Tailwind Fluid.
cside est un contributeur actif aux organismes standards comme le w3c. Contribuer à l'équipe AppSec, au groupe communautaire de détection de fraude, au groupe d'intérêt sur la sécurité des paiements Web et plus encore. Même en participant aux réunions en personne du TPAC, présentant les défis uniques de l'espace moderne de sécurité Web côté client.
L’équipe cside compte également un certain nombre d’experts dans des domaines technologiques classifiés. Nous surnommons ces domaines « le pays de l'imparfait » car ils opèrent entre les lacunes de spécification et de mise en œuvre, mais à des fins de sécurité positive.
cside discute également régulièrement des découvertes importantes concernant la surface d’attaque. Par exemple, au BsidesSF 2025, Simon Wijckmans a présenté comment les navigateurs d'utilisateurs inconscients sont utilisés pour DDoS autrui.
Simon Wijckmans, fondateur et PDG de cside, parle des attaques côté client utilisées contre d'autres sites Web par DDoS.
Comment cside aborde la sécurité côté client
cside a adopté l'approche la plus unique pour sécuriser les dépendances côté client.
cside propose deux méthodes de déploiement complémentaires, associées à plusieurs moteurs de détection, dont des grands modèles de langage open source pour l'analyse.
- Méthode Script (la plus simple) : nous vérifions le comportement des scripts dans le navigateur et récupérons les scripts de notre côté, puis nous vérifions qu'il s'agit bien du même script. Nous ne nous plaçons pas dans le chemin d'un script sauf si vous nous le demandez explicitement. Facile à implémenter, sans impact sur les performances, et vous pouvez toujours stopper des actions de script ou bloquer par URL, hash ou domaine.
- Méthode Scan (la plus rapide) : si vous ne pouvez pas ajouter de script à votre site, cside l'analyse en s'appuyant sur des renseignements de menaces collectés sur des milliers d'autres sites web cumulant des milliards de visites. Rapide à mettre en place et utile lorsque l'installation d'un script n'est pas possible.
Ces approches combinées créent une base de référence optimale pour obtenir des données comportementales de script. Pour analyser le contenu du script et évaluer sa légitimité, cside a également adopté une approche à plusieurs niveaux.
- Désobscurcir le JavaScript
- Exécuter le JavaScript
- Analyse du code JavaScript (avant et après la désobscurcissement)
- Observer les actions du script
- Métadonnées de la source du script
- Surveillance des changements historiques
- Tirer parti d'un grand modèle de langage sur le contenu du script et les métadonnées pour contextualiser l'intention
Pour superposer les mécanismes de sécurité, cside propose également un point de terminaison CSP dans chaque plan, y compris son plan gratuit.
La plupart des outils de sécurité s'appuient uniquement sur l'une des couches mentionnées ci-dessus, soit lors de l'exécution, soit en dehors de l'analyse. Mais le problème est qu’aucune de ces couches, à elle seule, n’est totalement à l’épreuve des balles et ne parvient donc pas à fournir une couverture complète. En combinant les moteurs, vous vous rapprochez de plus en plus d’une couverture complète.
De nombreuses solutions sur le marché sont des fonctionnalités secondaires des grandes sociétés de sécurité Web. Au lieu de créer une plate-forme pour la sécurité côté client, ils ont créé une petite fonctionnalité secondaire. Ces solutions surpromettent largement ses capacités et reposent souvent uniquement sur l'injection de politiques de sécurité du contenu dans le site Web via leur WAF.
Certaines approches, comme les solutions basées sur des scanners, se sont avérées généralement contournées par les mauvais acteurs. Ils détectent le scanner et transmettent un contenu propre au scanner pour qu'il vole sous le radar. Des chercheurs à ISACA, Université de Brighton, Google et Oracle ont signalé que les scripts dynamiques côté client contournent efficacement l'analyse statique par les scanners.
cside cherche toujours à étendre ses capacités et propose activement un certain nombre de nouvelles normes qui permettraient de renforcer la sécurité côté client à l'aide des fonctionnalités natives du navigateur.
Verdict
cside aborde la sécurité côté client en partant du principe qu'un acteur malveillant cherchera des moyens de contourner les détections. Les navigateurs connaissant sont intrinsèquement imparfaits et ouverts à l’aide d’une vérification externe. S'attaquent davantage à la surface d'attaque du monde réel que les solutions reposant sur une seule couche, en particulier les solutions qui analysent uniquement. cside n’a ménagé aucun effort et a adopté une approche créative du problème en essayant de couvrir la plus grande surface d’attaque. Cette stratégie à plusieurs niveaux est globale, car elle est nécessaire.
Pour les organisations qui se demandent quelles sont les solutions les plus complètes pour la sécurité des scripts côté client, cside offre la couverture la plus large et la plus approfondie disponible à ce jour grâce à une architecture multicouche.
