Comment contourner les agents JavaScript, les CSP et les crawlers (tests de sécurité côté client)

TL;DR :

• Les scripts côté client utilisés pour les vérifications de sécurité peuvent être rendus inefficaces à l'aide de fonctionnalités standard du navigateur, comme les redéfinitions XHR.
• Bien que cela puisse être évité, nous n'avons pas réussi à trouver un fournisseur ayant mis en œuvre une méthode de prévention, ce qui rend les solutions de sécurité vulnérables aux contournements.
• Les solutions sans crawler/scanner/agent souffrent par conception d'une visibilité limitée. Cela permet à un acteur malveillant de détecter les scans et de piéger le scanner de sécurité en lui servant du code bénin, tout en servant du code malveillant aux utilisateurs finaux.
• L'objectif de cet article est d'aider à sensibiliser aux risques des attaques côté client et aux exploits que les acteurs malveillants utilisent pour rendre les solutions de sécurité impuissantes. Nous proposons également des solutions pour prévenir ces méthodes de contournement.

Dans ce blog :

• Pourquoi vous devriez tester vos outils de conformité
• Comment contourner les agents JavaScript
• Comment contourner la CSP
• Comment contourner les crawlers
• Conseils de défense et alternatives plus sûres
• Avertissements et divulgation responsable

Objectif et périmètre. Cet article est publié à des fins éducatives et défensives uniquement. Les exemples visent à expliquer le comportement général du navigateur et les limitations de conception pouvant affecter les outils de sécurité côté client ; il ne s'agit pas d'un manuel d'attaque étape par étape, et ils ne ciblent aucun fournisseur, produit ou organisation en particulier. Nous ne cautionnons pas l'utilisation illicite des techniques abordées ici. Si vous découvrez une vulnérabilité liée au contenu de cet article, veuillez suivre la divulgation responsable — voir la section « Divulgation responsable » à la fin de cet article. Tous les tests ont été effectués conformément aux conditions d'utilisation applicables des fournisseurs et aux lois en vigueur.

« Dans un monde où les outils de conformité peuvent échouer face à des techniques de contournement élémentaires, personne n'est vraiment plus en sécurité, et les faux sentiments de sécurité aggravent les problèmes. »

- Simon Wijckmans, CEO, cside

Pourquoi vous devriez tester vos outils de conformité / sécurité côté client

Nous avons longuement hésité avant d'écrire cet article. D'un côté, nous ne souhaitons pas pointer du doigt des fournisseurs. De l'autre, lorsque des solutions de sécurité sont vendues mais peuvent être facilement contournées, nous sommes tous en danger. Nous avons créé cside pour bâtir un internet plus sûr, avec l'ambition de réduire l'anxiété liée à la sécurité en ligne.

Cela implique parfois de mettre en lumière les failles des périmètres de sécurité, surtout lorsqu'elles découlent de contraintes bien connues de la plateforme.

Nous comprenons que pour de nombreuses entreprises, la conformité se résume à cocher une case. Nous voyons la conformité comme une opportunité d'améliorer la sécurité d'une plateforme — d'autant plus que ces exigences ont été créées précisément pour empêcher l'exécution d'attaques.

Imaginez un détecteur de fumée dernier cri qui détecte parfaitement un incendie, mais dont le fil d'alarme est coupé avant qu'il puisse sonner l'alerte. La détection est parfaite, mais la réponse n'a jamais lieu. C'est la réalité dangereuse de certaines solutions de sécurité côté client opérant dans un navigateur web.

Lorsqu'un navigateur charge une page, les scripts s'exécutent dans le même environnement JavaScript et peuvent interagir avec des objets globaux partagés. Dans certaines conditions, cela peut permettre à un script d'observer ou de modifier un autre. Même des détections côté client sophistiquées peuvent être limitées si leur reporting sortant est perturbé. C'est un risque concret que les défenseurs doivent prendre en compte lorsqu'ils s'appuient uniquement sur la télémétrie côté client. Un script malveillant peut interférer avec le reporting sortant d'un outil de sécurité, ce qui peut dans certains cas réduire considérablement la visibilité sur un incident en cours.

C'est pourquoi cside a décidé de ne pas s'appuyer entièrement sur des détections côté client, mais d'opter pour une approche plus avancée et nuancée.

Comment contourner un agent JavaScript

Le principal moyen pour un navigateur de communiquer avec un serveur est via des requêtes réseau, généralement en utilisant l'API fetch ou XMLHttpRequest (XHR). Pour un développeur, ces éléments peuvent sembler fondamentaux et immuables. En réalité, ce sont simplement des propriétés de l'objet global window que n'importe quel script peut redéfinir.

De nombreux scripts légitimes interagissent avec l'API fetch — c'est une approche courante et généralement connue.

Cependant, un script peut exploiter ces API pour interagir avec les appels sortants des fournisseurs de sécurité côté client. Cela se fait facilement en :

• Redéfinissant window.fetch pour inspecter ou bloquer les rapports de sécurité sortants.
• Modifiant XMLHttpRequest.prototype.send pour intercepter et supprimer les alertes.
• Enveloppant ces fonctions pour altérer les charges utiles des requêtes, supprimer les en-têtes de sécurité ou journaliser des données sensibles.

Voyons à quel point c'est simple. Imaginez que votre site charge deux scripts :

1. Un plugin de chat tiers qui a été compromis.
2. Un outil de sécurité.

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>My Application</title>
  <script src="https://false-sense-of-security.com/security.js"></script>

  <script src="https://compromised-chat-plugin.com/plugin.js"></script>
</head>
<body>
  </body>
</html>

Voici le code que le plugin.js compromis pourrait contenir. Comme de nombreux scripts le font à des fins légitimes, il interagit avec l'API navigateur XMLHttpRequest. Voici un comportement logiciel général illustratif.

// NON-EXECUTABLE: conceptual attacker flow (illustrative only)
// This block intentionally avoids runnable JS. It explains the high-level
// steps an attacker might take to interfere with client-side telemetry.
// DO NOT paste this into a JS runtime expecting it to run — it's purely descriptive.
/
  Conceptual steps an attacker could use (high-level):
    1) DETECT_TELEMETRY_SENDER(stack): use heuristics / runtime markers to guess
       which script is attempting to send telemetry.
    2) INTERCEPT_OUTBOUND_CALL(request): short-circuit, modify, or drop the request.
    3) LOG_DECISION(info): optionally record that a telemetry call was suppressed.
/
/* ---------- Conceptual operations (NOT real functions) ---------- */
DETECT_TELEMETRY_SENDER(stack)
// returns: SENDER_MATCHED | NO_MATCH
// NOTE: "stack" is a conceptual representation of runtime context
INTERCEPT_OUTBOUND_CALL(request)
// possible outcomes (conceptual): DROP | MODIFY(request) | FORWARD(request)
LOG_DECISION(info)
// record decision for analysis (conceptual)
/* ---------- Simulated scenario (text-only) ---------- */
// Simulated runtime: the attacker inspects the current call stack (conceptually)
SIMULATED_STACK = "...security.js at ..."
// Conceptual detection step
DETECT_RESULT => DETECT_TELEMETRY_SENDER(SIMULATED_STACK)  // => SENDER_MATCHED
// Conceptual interception decision
INTERCEPT_OUTCOME => INTERCEPT_OUTBOUND_CALL({ to: "/telemetry" })  // => DROP
// Simulated log
LOG_DECISION("Telemetry report suppressed (conceptual)")
/* ---------- Simulated console output (for reader comprehension) ---------- */
// >> DETECT_TELEMETRY_SENDER(...) => SENDER_MATCHED
// >> INTERCEPT_OUTBOUND_CALL(...) => DROP
// >> LOG: "Telemetry report suppressed (conceptual)"

Avec ce comportement de code en place, votre outil de sécurité est effectivement neutralisé. Il peut encore détecter un comportement malveillant, mais ses appels à l'aide (requêtes fetch ou XHR) sont interceptés et jetés dans le vide. Vous ne saurez jamais qu'une attaque a eu lieu.

Comment prévenir ce problème

Prévenir ce problème pour les requêtes fetch est très simple : il suffit d'en copier une version locale, sans même avoir besoin de la renommer.

// Stocker `fetch` localement pour le réutiliser plus tard :
const { fetch } = window;

// Utiliser la version locale de fetch plus loin dans le code :
fetch(...)

XHR demande un peu plus de travail, mais reste faisable en quelques lignes de code.

// Stocker les prototypes localement pour les réutiliser plus tard :
const { apply } = Reflect;
const { open, send } = XMLHttpRequest.prototype;
const { XMLHttpRequest } = window;

// Dans une partie asynchrone du code :
const request = new XMLHttpRequest();
apply(open, request, ["POST", "/endpoint"]);
apply(send, request, []);

Notre analyse des méthodologies de détection courantes suggère que ces solutions pourraient être vulnérables aux concepts de contournement documentés ci-dessus.

Nous recommandons vivement à tout fournisseur de sécurité d'examiner ces approches afin de mieux protéger ses clients.

Tout script de sécurité doit s'exécuter en premier. Dans le cas contraire, un acteur malveillant peut détourner les API que le script de sécurité tente de protéger. C'est une exigence fondamentale.

Comment contourner une solution « sans agent »

De nombreux fournisseurs proposent une approche « sans agent ». Il s'agit en pratique d'un scanner ou d'un crawler hébergé sur une plateforme cloud. Comme toute application, les requêtes réseau doivent provenir de quelque part. Et pour la plupart de ces solutions, elles proviennent d'une adresse IP appartenant à des fournisseurs cloud.

Lorsqu'une requête réseau est effectuée, un en-tête de requête est envoyé, contenant un certain nombre de données précieuses.

Host, User-Agent, Accept-Language, Referer (orthographe intentionnellement incorrecte) et bien d'autres.

L'infrastructure d'un script récupéré côté client voit ces valeurs et décide de servir des versions spécifiques du script. C'est logique et justifié. Un outil marketing peut servir différentes versions de son script selon le navigateur utilisé ou la localisation de l'utilisateur, pour simplifier la conformité à la vie privée. De même, les publicités par exemple sont aléatoires, elles changent constamment et sont des JavaScripts côté client. Les scripts côté client sont des fonctionnalités dynamiques et de nombreuses solutions ont besoin de ces capacités dynamiques.

Cependant, c'est une opportunité pour un acteur malveillant. Pour illustrer :

// Illustrative pseudo-logic; not intended for production or misuse.
const CLOUD_ASNS = new Set([
// Common Cloud provider ASNs. Add more if needed
16509, // AMAZON-02
14618, // AMAZON-AES
24940, // HETZNER
212317, // HETZNER
398657, // MICROSOFT AZURE DEDICATED
]);
export default {
async fetch(request) {
// server adds network info on the request
const asn = request.xyz?.asn;
<span class="kw">const</span> body = CLOUD_ASNS
  ? <span class="str">`console.log("we're good");\n`</span>
  : <span class="str">`console.log("we're bad");\n`</span>;

<span class="kw">return new</span> Response(body, {
  headers: {
    <span class="str">"content-type"</span>: <span class="str">"application/javascript; charset=utf-8"</span>,
    <span class="str">"cache-control"</span>: <span class="str">"no-store"</span>,
  },
});

},
};

L'exemple ci-dessus peut être déployé sur n'importe quel type de serveur web, y compris des plateformes PaaS simples ne nécessitant aucune vérification particulière.

Ce que fait ce script est assez simple. Lorsqu'une requête provient d'un fournisseur cloud, il sert un script propre. Toute autre requête reçoit un script malveillant.

Bien entendu, l'acteur malveillant pourrait ajouter davantage de logique. Par exemple, ne servir le mauvais script que si les outils de développement sont fermés et seulement 5 % du temps, rendant la détection par revue manuelle plus difficile.

Cela peut réduire considérablement la visibilité qu'une solution basée sur des crawlers a sur les attaques ciblées.

Utiliser un proxy résidentiel pour paraître comme un utilisateur résidentiel normal est peu susceptible de faire une différence significative. Un acteur malveillant peut toujours détecter l'utilisation d'un proxy résidentiel.

La plage d'adresses IPv4 compte 4,3 milliards d'adresses IP, l'IPv6 340 undécillions (oui, ce mot existe), les user-agents des navigateurs changent constamment... il existe des niveaux d'entropie infinis et un acteur malveillant peut toujours échantillonner une attaque. En fin de compte, aucune méthode artificielle pour faire paraître quelque chose humain n'est réellement humaine. Les acteurs malveillants investis trouveront toujours des moyens de différencier un vrai utilisateur humain d'un flux de travail automatisé. Les pages marketing des fournisseurs peuvent vous faire croire le contraire, mais les faits techniques restent des faits techniques.

Une autre méthode simple consiste à effectuer une sous-requête côté client basée sur les paramètres disponibles dans le navigateur. Cela permet d'utiliser toute l'étendue des API du navigateur pour décider si une sous-requête doit être effectuée ou non.

De nombreuses solutions basées sur des crawlers vérifient simplement l'URL source par rapport à une liste de noms de domaines malveillants connus, obtenue auprès de fournisseurs de flux de menaces. Le problème avec cette approche est qu'une attaque ciblée ne sera pas signalée et qu'il peut s'écouler beaucoup de temps avant qu'une attaque soit remarquée. Les acteurs malveillants peuvent également facilement éviter la détection de domaines malveillants en utilisant des noms de domaine couramment utilisés comme googletagmanager.com pour héberger les scripts malveillants.

Une solution basée sur des crawlers aborde une menace de sécurité dynamique avec un état d'esprit de sécurité statique. Bien que pratique, cela ne fonctionne pas par conception. Pour illustrer davantage ce point, passons en revue quelques méthodes d'attaque courantes et la façon dont elles contournent la détection.

Attaques géolocalisées (Geofencing)

Ce qu'elles sont : Les attaques géolocalisées ne servent un script malveillant qu'aux utilisateurs situés dans des emplacements ou des plages d'IP spécifiques (par exemple, certaines plages d'opérateurs mobiles au Royaume-Uni ou dans l'UE) et servent un script bénin à tous les autres.

Pourquoi les scanners les manquent :

• Les scanners, crawlers et outils « sans agent » fonctionnent presque toujours depuis des IP de fournisseurs cloud ou des plages de proxies connus.
• Les attaquants peuvent facilement maintenir une liste d'ASN cloud et éviter d'envoyer des charges malveillantes à ces IP.
• En conséquence, le scanner voit à répétition le script « propre » et n'observe jamais la vraie attaque.

Pourquoi cside les détecte :

• cside observe les scripts tels qu'ils s'exécutent dans les navigateurs de vrais utilisateurs, sur de vrais réseaux résidentiels et mobiles.
• Si un script se comporte de manière malveillante pour un vrai utilisateur, cside peut détecter le comportement et, en mode gardien, même bloquer la charge utile avant qu'elle ne s'exécute.

En d'autres termes, Reflectiz voit ce que les attaquants permettent à leurs scanners de voir ; cside voit ce que les attaquants envoient réellement à vos utilisateurs.

Attaques ciblant le User-Agent

Ce sont des attaques où une charge malveillante n'est injectée que sur certains navigateurs, par exemple selenium, Safari, Chromium ou un système d'exploitation spécifique.

La plupart des scanners, crawlers et solutions « sans agent » proviennent d'une gamme de chaînes User-Agent prévisibles. Ils émulent rarement les en-têtes d'appareils mobiles.

Et dans les rares cas où un scanner change ses User-Agents, l'agent ne correspond généralement pas aux charges utiles réelles des requêtes. Les scanners fonctionnent généralement sur des systèmes d'exploitation Linux, ce qui signifie qu'un acteur malveillant remarquera, d'après le paquet de requête TCP, quel système d'exploitation est réellement utilisé. Résultat : la charge malveillante n'est pas envoyée au scanner, car Linux est rarement utilisé par un vrai utilisateur humain.

Attaques à fenêtre temporelle

Ce sont des attaques qui ne s'exécutent qu'à des moments précis de la journée. Par exemple : en dehors des heures de bureau, lorsque les équipes de sécurité ne sont pas présentes. Les scanners fonctionnent périodiquement, donc une approche temporellement délimitée peut facilement faire en sorte que le script bénin soit scanné, mais pas le script malveillant.

Exécution de code masquée ou conditionnelle

Ce sont des attaques qui exploitent les actions des utilisateurs pour injecter un script malveillant. Toute l'étendue des API du navigateur peut être utilisée ici, par exemple en vérifiant les mouvements de souris, en exigeant un certain rythme de saisie au clavier, en vérifiant l'existence de cookies, en effectuant une analyse temporelle (utilisée pour détecter les navigateurs sans interface graphique)...

Cette méthode est couramment utilisée pour ne servir la charge malveillante qu'une seule fois, de sorte qu'un chercheur en sécurité ne puisse pas retrouver la charge malveillante. C'est particulièrement difficile car les outils de développement des navigateurs ne stockent souvent pas les états précédents d'avant leur ouverture, rendant un rechargement nécessaire.

Un scanner ne sera jamais capable d'émuler le comportement réel d'un utilisateur de la même façon qu'un vrai utilisateur.

Charges utiles dynamiques par session

Ce sont des attaques où l'acteur malveillant génère automatiquement des charges malveillantes uniques pour chaque vrai utilisateur, en utilisant des techniques comme l'enveloppement de scripts avec des clés dynamiques, du JavaScript polymorphique, une logique de type test A/B... Souvent en utilisant les indicateurs d'authentification de l'utilisateur comme condition pour injecter les charges malveillantes.

Empoisonnement intermittent de la chaîne d'approvisionnement

C'est une méthode extrêmement courante utilisée dans les attaques de style Magecart. Un acteur malveillant peut simplement échantillonner l'attaque pour ne servir le contenu du script malveillant qu'à 1 % des utilisateurs. Cette méthode rend beaucoup plus difficile pour un visiteur de remarquer l'attaque, car l'injection totalement aléatoire du script rend la reproduction de l'attaque beaucoup plus difficile.

Conclusion

Sur la base des capacités fondamentales du navigateur documentées publiquement et des fonctionnalités JavaScript standard, les approches basées sur des crawlers peuvent faire face aux limitations décrites ci-dessus.

Nous encourageons les fournisseurs à documenter clairement ces limitations et à ne pas surestimer leurs capacités. Les clients doivent disposer des informations nécessaires pour prendre des décisions de déploiement éclairées, dans le meilleur intérêt de la sécurité du web.

Comment contourner la CSP

Une autre approche de sécurité couramment utilisée est la politique de sécurité du contenu (Content Security Policy).

La CSP peut être utile pour limiter l'exposition en réduisant la portée des sources autorisées. Mais de nombreux sites web utilisent des outils ouverts au monde entier pour y télécharger des scripts. Si une politique n'est pas suffisamment stricte, cela mènera à un contournement facile. Mais même si une politique est suffisamment stricte, un attaquant peut choisir d'effectuer l'attaque d'une manière que la CSP ne surveille pas.

Voici comment cela fonctionnerait. Une fois qu'un acteur malveillant s'est introduit dans une application web, il peut injecter une sous-requête vers un conteneur Google Tag Manager. Exemple :

<script async src="https://www.googletagmanager[.]com/gtm.js?id=GTM-XXXXXX"></script>

À l'intérieur de ce conteneur, il peut inclure n'importe quel script souhaité, y compris des scripts en ligne qui sont encore plus difficiles à sécuriser.

Comme la CSP n'a pas de contexte réel sur le contenu des scripts, la visibilité est assez limitée.

Certaines solutions tentent de remédier à cela en effectuant un fetch vers le script après coup.

Mais le même problème que pour le crawler se poserait : tout ce qui semble non humain recevra probablement une réponse différente de celle qu'un utilisateur humain obtiendrait.

Bien que vous puissiez spécifier le conteneur Tag Manager dans la CSP, ce n'est pas très courant. Il existe également d'autres domaines comme « githubusercontent[.]com » qui font face au même problème.

Et en fin de compte, si une source est compromise, que ce soit par un incident chez le fournisseur ou par l'expiration du nom de domaine, la CSP sera incapable d'aider.

Contrairement à la méthode des scripts côté client, nous n'avons pas réussi à trouver une technique fiable dans la CSP qui éviterait d'utiliser un domaine de confiance comme méthode de contournement. Les propriétaires de domaines pourraient eux-mêmes prendre des mesures préventives, mais ne l'ont pas fait à ce jour. La CSP a des limites, mais comme pour tout programme de sécurité, la superposition des couches est une bonne pratique. La CSP est utilisée pour plus que ce pour quoi elle a été initialement conçue.

Les entreprises qui adoptent la CSP ont souvent du mal à la maintenir et font face à des interruptions régulières des outils côté client lorsque les politiques bloquent des changements.

cside est activement impliqué dans les organisations de standards web pour tenter d'améliorer la spécification de la CSP et d'autres méthodes comme SRI.

Des alternatives plus sûres (l'approche cside)

L'équipe cside possède une expérience substantielle en matière de sécurité côté client. Au fil de nos expériences, nous avons identifié que les acteurs malveillants opèrent à un niveau de sophistication qui prend le dessus sur certaines approches de sécurité. Si la récompense est élevée, toute lacune dans un modèle de détection de sécurité est une opportunité pour un acteur malveillant.

Compte tenu des limitations de la spécification des navigateurs pour la sécurité côté client, nous avons dû faire preuve de créativité, c'est pourquoi nous avons abordé la sécurité côté client différemment de toute autre solution sur le marché.

• Mode Direct - Le plus simple : Nous vérifions les comportements des scripts dans le navigateur et récupérons les scripts de notre côté. Nous vérifions ensuite que nous avons obtenu le même script. Nous ne nous plaçons pas dans le chemin d'un script à moins que vous ne nous le demandiez explicitement. Un seul script à ajouter au site, cela prend quelques secondes.
• Mode Gardien - Le plus sûr : Nous vérifions les comportements des scripts et cside se place au milieu entre le tiers non contrôlé et l'utilisateur final — uniquement pour les scripts auxquels vous ne faisiez pas déjà confiance. Un seul script à ajouter au site, cela prend quelques secondes.
• Mode Scan - Le plus rapide : Si vous ne pouvez pas ajouter un script au site, cside le scannera. Nous utiliserons l'intelligence sur les menaces cside collectée par des milliers d'autres sites web avec des milliards de visiteurs combinés pour aider à sécuriser votre site du mieux possible.

La combinaison de ce qui précède nous rapproche le plus de la couverture complète techniquement possible aujourd'hui.

En bonus, avec certaines des approches que nous avons adoptées, nous avons pu rendre les sites web plus rapides selon les scripts présents sur la page. Placer une solution au milieu ne ralentit les choses que si elles sont déjà entièrement optimisées, ce qui n'est souvent pas le cas.

Avec cela, cside aide les entreprises à atteindre la conformité, qu'elle soit axée sur la sécurité ou la confidentialité.

cside contribue activement au W3C dans l'espoir d'attirer l'attention sur la sécurité côté client, en visant à apporter des ajustements à la spécification du navigateur pour permettre une sécurité côté client totalement à l'épreuve des balles.

Chez cside, nous capturons les attaques. Si vous lisez cet article, vous êtes probablement une cible suffisamment précieuse pour qu'un acteur malveillant investisse un certain niveau de capacité mentale à inspecter le fonctionnement de votre sécurité web. Il vaut mieux être prudent et supposer qu'un acteur malveillant tentera de contourner les solutions de sécurité que vous utilisez. Utilisez donc des solutions qui pensent une longueur d'avance.

Avertissement et protection juridique

Cet article est fourni à des fins d'information et d'éducation uniquement. Il ne constitue pas un conseil juridique, et les points de vue et analyses techniques exprimés sont les nôtres. Rien ici ne doit être interprété comme une admission de responsabilité de quelque partie que ce soit.

Aucune des approches ou des exemples de code mentionnés ci-dessus n'est avancé ou utilisé exclusivement à des fins malveillantes. Il s'agit de cas d'utilisation JavaScript de base, en aucun cas propriétaires. Les extraits partagés sont activement utilisés dans des scripts côté client à des fins légitimes. Nous ne sommes pas responsables de l'utilisation de ces fonctions JavaScript de base par une partie malveillante.

Tous les exemples de code et pseudo-code sont illustratifs uniquement. Ils sont intentionnellement génériques, non propriétaires et non conçus pour fonctionner dans des environnements réels. Leur objectif est de mettre en évidence des considérations défensives, non de fournir aux attaquants des exploits fonctionnels.

Veuillez noter : tenter d'appliquer ces techniques sur des systèmes que vous ne possédez pas, ou sans autorisation explicite, peut violer des lois telles que le U.S. Computer Fraud and Abuse Act, le UK Computer Misuse Act, ou des règles similaires dans d'autres juridictions.

Nous soutenons activement la recherche en sécurité de bonne foi. Si vous suivez le processus de divulgation responsable décrit ci-dessous, nous traiterons votre recherche comme autorisée et n'engagerons pas de poursuites judiciaires contre vous. En résumé, ce contenu est fourni pour aider les défenseurs à renforcer les protections, non pour permettre des comportements malveillants.

Divulgation responsable

Si vous pensez avoir découvert une vulnérabilité liée au contenu de cet article (y compris des scripts tiers ou des intégrations que nous référençons), veuillez ne pas publier les détails de l'exploit publiquement. Envoyez-nous plutôt un e-mail à

hello@cside.com avec pour objet « Vulnerability report [titre court] ».

Incluez les étapes reproductibles, les URL affectées et un moyen de contact sécurisé. Nous accuserons réception dans les 5 jours ouvrables et coordonnerons la remédiation. Nous n'engagerons pas de poursuites judiciaires contre les rapporteurs de bonne foi qui respectent ces directives.