Politique de divulgation des vulnérabilités

La présente politique définit les conditions dans lesquelles toute personne peut rechercher, puis signaler à l'éditeur, une vulnérabilité de sécurité affectant la plateforme RackList. Elle vaut autorisation expresse et écrite de mener les tests décrits à l'article 3, dans les limites fixées aux articles 4 et 5. Elle s'adresse à quiconque, sans condition de compte, de nationalité, de qualification professionnelle, ni d'adhésion préalable à un quelconque programme.

Chercheur

Toute personne qui recherche, découvre ou signale une vulnérabilité relevant de la présente politique. Aucune inscription préalable n'est requise.

Éditeur

Alexandre ETEOCLE, entrepreneur individuel, éditeur de la plateforme RackList et responsable du traitement au sens du RGPD.

Plateforme

Le site racklist.eu et les seuls services que l'éditeur exploite lui-même, énumérés à l'article 3.

Vulnérabilité

Un défaut de conception, de configuration ou d'implémentation permettant de porter atteinte à la confidentialité, à l'intégrité ou à la disponibilité de la plateforme ou des données qu'elle traite.

Divulgation coordonnée

Le processus par lequel le chercheur informe d'abord l'éditeur, lui laisse le délai prévu à l'article 7 pour corriger, puis publie s'il le souhaite.

Vous êtes autorisé à mener des tests non destructifs sur les éléments suivants, exploités par l'éditeur :

• Le site racklist.eu et ses sous-domaines exploités par l'éditeur, y compris l'espace personnel, l'espace hébergeur et les interfaces d'administration atteintes avec vos propres identifiants.
• L'interface de programmation publique de la plateforme, appelée avec une clé rattachée à votre propre compte.
• Le composant embarquable distribué par la plateforme et destiné à être intégré sur des sites tiers.
• Le code exécuté dans votre navigateur : gabarits, scripts, feuilles de style, en-têtes de sécurité, politique de sécurité du contenu.
• Les courriels transactionnels émis par la plateforme vers votre propre adresse, ainsi que les mécanismes de vérification d'expéditeur du domaine.
• Les parcours d'authentification, de fédération d'identité et de gestion de session, éprouvés sur des comptes que vous contrôlez.

Les éléments suivants n'appartiennent pas à l'éditeur ou ne relèvent pas de son autorisation. Il n'a pas le pouvoir de vous autoriser à les tester, et ne le fait pas :

• L'infrastructure physique, matérielle et réseau qui porte le service. Les serveurs sont opérés par OVH SAS, dont les conditions et la procédure de signalement propres s'appliquent. Cette infrastructure est mutualisée : elle supporte d'autres services que RackList, et un test qui la vise atteint des tiers étrangers à la plateforme.
• Les services tiers auxquels la plateforme fait appel, notamment le réseau de diffusion et de protection (Cloudflare, Inc.), le prestataire de paiement (Stripe Payments Europe Ltd.) et les fournisseurs d'identité fédérée (Google, GitHub, Discord et ClientXCMS, exploité par clientxcms.com). Chacun exploite sa propre procédure de signalement, à laquelle il faut vous adresser. Seule l'intégration de ces services au sein de la plateforme relève de la présente politique, à l'exclusion des services eux-mêmes.
• Les sites, espaces clients et infrastructures des hébergeurs référencés sur RackList. Un hébergeur référencé n'est ni un client ni un sous-traitant de l'éditeur : le référencement ne vaut aucune autorisation de test, sous aucune forme.
• Les espaces communautaires hébergés par des plateformes tierces, notamment le serveur Discord de la communauté.
• Les personnes : équipe, contributeurs, utilisateurs, personnels des hébergeurs référencés, ainsi que leurs comptes et leurs appareils personnels.
• Les locaux, le matériel et les supports physiques.

Quel que soit le périmètre, les techniques suivantes sont interdites. Leur emploi fait perdre le bénéfice de l'article 8 et peut constituer une infraction pénale :

• Le déni de service sous toutes ses formes : saturation de bande passante, épuisement des ressources applicatives ou de la base de données, envoi massif de requêtes, test de charge, campagne de force brute non concertée.
• L'ingénierie sociale visant l'équipe de RackList, ses contributeurs, ses utilisateurs ou les hébergeurs référencés : hameçonnage, usurpation d'identité, prétexte téléphonique, sollicitation d'un accès ou d'un identifiant.
• Tout test touchant les données réelles d'un autre utilisateur : lecture, modification, suppression ou altération d'un compte, d'un avis, d'un message privé ou d'une fiche que vous ne contrôlez pas.
• L'exfiltration de données au-delà de la preuve strictement minimale. Dès que la faille est démontrée, arrêtez-vous : quelques enregistrements ou un identifiant tronqué suffisent. Ne copiez aucune base, ne téléchargez aucun jeu de données, ne conservez rien au-delà du signalement.
• L'installation d'une porte dérobée, d'un implant ou d'un compte caché, et toute action visant à conserver un accès dans la durée.
• La destruction, la modification ou le chiffrement de données, la dégradation d'un service, la modification visible du site.
• Le balayage automatisé agressif de la production, sans concertation préalable avec l'éditeur.

Adressez votre signalement par courrier électronique à l'adresse ci-dessous. Le français et l'anglais sont acceptés. Un accusé de réception vous est adressé dans le délai prévu à l'article 7.

security@racklist.eu

Un rapport exploitable contient :

• La description de la vulnérabilité et du composant affecté.
• Les étapes exactes permettant de la reproduire, dans l'ordre.
• L'impact que vous estimez, et le pire scénario que vous entrevoyez.
• La preuve minimale : une capture, une requête, un extrait tronqué. Rien de plus.
• L'horodatage de vos tests et les adresses source utilisées, afin que nous puissions distinguer votre activité d'une attaque réelle.
• Le nom ou le pseudonyme sous lequel vous souhaitez être reconnu, si vous le souhaitez.

Ne constituent pas un signalement recevable : la sortie brute d'un outil de balayage sans analyse ni démonstration d'impact, un écart de configuration sans conséquence exploitable, et un résultat déjà couvert par un signalement en cours de traitement.

Vous pouvez, en parallèle ou à la place, transmettre votre information à l'Agence nationale de la sécurité des systèmes d'information dans les conditions de l'article L. 2321-4 du code de la défense, qui impose à l'agence de préserver la confidentialité de votre identité. Ce canal s'ajoute au nôtre, il ne s'y substitue pas, et il ne dispense pas des règles de la présente politique.

L'éditeur est une structure de petite taille. Les délais ci-dessous sont ceux qu'il peut réellement tenir, ils ne sont pas décoratifs.

Accusé de réception

5 jours ouvrés à compter de la réception du signalement.

Qualification

15 jours ouvrés : nous vous indiquons si la vulnérabilité est retenue, la gravité que nous lui donnons et la suite envisagée.

Correction

90 jours calendaires visés pour une vulnérabilité retenue. Une vulnérabilité critique et activement exploitable est traitée en priorité, sans attendre ce terme.

Divulgation publique

Vous êtes libre de publier à l'expiration d'un délai de 90 jours calendaires courant à compter de l'accusé de réception, que la correction soit intervenue ou non. Nous pouvons vous demander un report motivé, nous ne pouvons pas vous l'imposer. Une publication anticipée d'un commun accord est possible dès le déploiement du correctif.

Notre silence n'est pas un refus, mais il ne vous engage pas indéfiniment. Sans accusé de réception au bout de 5 jours ouvrés, relancez-nous. Passé 30 jours calendaires sans la moindre réponse de notre part, vous êtes délié de l'obligation de coordination et libre de publier.

Les tests menés dans le respect intégral des articles 3, 4, 5 et 6 sont expressément autorisés par l'éditeur. C'est le point essentiel de ce document : un accès autorisé n'est pas un accès frauduleux au sens des articles 323-1 et suivants du code pénal.

L'autorisation donnée ci-dessus est subordonnée au signalement. Toute vulnérabilité découverte doit nous être signalée sans délai injustifié, et au plus tard dans les 72 heures suivant sa découverte. Un délai supérieur reste admis s'il est nécessaire à l'analyse et qu'il nous est annoncé dans ce même délai. À défaut, l'autorisation cesse rétroactivement de couvrir les tests concernés et l'accès correspondant redevient un accès non autorisé. Conserver, exploiter, transmettre ou céder une vulnérabilité non signalée place son auteur hors de la présente politique, quelle qu'ait été son intention initiale.

Si un tiers engage néanmoins une action contre un chercheur au titre de travaux couverts par la présente politique, l'éditeur s'engage à attester par écrit, à la demande du chercheur, que ces travaux étaient autorisés.

Un écart mineur, commis de bonne foi et immédiatement corrigé, ne fait pas perdre le bénéfice du présent article. C'est le comportement d'ensemble qui est apprécié, non la lettre. Le doute profite au chercheur qui a signalé plutôt que publié.

Cet engagement porte sur ce que l'éditeur maîtrise. Il ne lie ni les tiers mentionnés à l'article 4, ni l'autorité judiciaire, ni le ministère public, l'action publique n'appartenant pas à l'éditeur. Il ne couvre pas les faits relevant de l'article 5, ni un signalement assorti d'une exigence de contrepartie.

Un signalement retenu ouvre droit, au choix du chercheur :

• À une mention publique sur la page de reconnaissance des chercheurs, sous le nom ou le pseudonyme de votre choix.
• À l'anonymat complet. C'est le comportement par défaut : rien n'est publié à votre sujet sans votre accord.
• À l'accès au programme chasseur de bugs de RackList, qui ouvre un canal de signalement dédié et, le cas échéant, une contrepartie décrite dans le règlement propre à ce programme.

La mention publique n'intervient qu'après le déploiement du correctif, afin de ne pas désigner une faille encore ouverte.

La présente politique ne crée aucune obligation de récompense financière. Un signalement adressé hors du programme chasseur de bugs n'ouvre pas droit à une prime au seul titre du présent document.

Si vos tests vous exposent, même involontairement, à des données personnelles d'autrui, arrêtez immédiatement, ne consultez rien au-delà de ce qui prouve l'existence de la faille, ne les conservez pas, ne les transmettez à personne, et mentionnez-le dans votre rapport.

Supprimez toute copie dès que l'éditeur a accusé réception, et confirmez cette suppression par écrit. Leur conservation au-delà de ce point n'est plus couverte par la présente politique et relève du droit commun.

Les données que vous nous transmettez, adresse de contact, contenu du rapport et éléments techniques, sont traitées aux seules fins de qualification et de correction, sur la base de l'intérêt légitime de l'éditeur (RGPD art. 6.1.f), et conservées trois ans à des fins de preuve et de suivi. Vos droits s'exercent dans les conditions décrites dans la Politique de confidentialité.

La présente politique est versionnée. Sa version et sa date de dernière mise à jour figurent en tête de page. Le cadre applicable à un signalement est celui de la version en vigueur au jour de son envoi : une modification ultérieure ne peut pas vous être opposée rétroactivement. Lorsqu'une candidature au programme chasseur de bugs emporte acceptation de la présente politique, la version acceptée est conservée avec cette candidature.

La présente politique est régie par le droit français. Elle s'interprète en cohérence avec les Conditions Générales d'Utilisation de la plateforme. Elle ne constitue ni une renonciation aux droits de l'éditeur à l'égard de faits étrangers au périmètre qu'elle définit, ni une garantie donnée au nom d'un tiers. Tout litige relatif à son interprétation ou à son exécution est soumis aux tribunaux compétents du ressort du siège de l'éditeur.