Signalement de bonne foi et coordination des corrections.
Dernière mise à jour :
1. Objet de la politique
NoShortcuts Studio (« Studio »), SAS au capital de 1,00 €, 107 603 185 R.C.S. Lille Métropole, 31 rue du Général de Gaulle, 59133 Phalempin, France, souhaite faciliter le signalement responsable des vulnérabilités affectant son Site noshortcuts.studio.
Cette politique organise la réception d’un signalement et la coordination d’une correction. Elle vise à protéger les utilisateurs, leurs données, les créations du Studio et la disponibilité des services. Elle complète les CGU et la Politique de confidentialité.
2. Portée du signalement et limites de l’autorisation
Les failles concernant les pages, fonctionnalités et API exploitées par le Studio sous le nom exact noshortcuts.studio peuvent être signalées. Une découverte accidentelle concernant un autre actif peut également être transmise afin que le Studio identifie le bon interlocuteur, sans que cet envoi étende le périmètre de test.
La politique ne constitue pas une autorisation générale d’intrusion. La consultation normale de pages publiques et l’observation de vos propres échanges avec le service peuvent servir à établir un signalement. Pour toute vérification active allant au-delà de votre usage normal, demandez préalablement un accord écrit décrivant le système, les comptes, les méthodes, la période et les limites autorisés.
L’absence de réponse, l’absence de protection apparente ou l’existence d’une URL ne valent pas accord. Un compte personnel ou un rôle attribué ne vous autorise pas à tester des comptes de tiers ni à contourner une restriction.
3. Systèmes hors périmètre
Sont exclus des tests sans accord distinct : les sous-domaines non explicitement autorisés, les infrastructures des fournisseurs, OVH, les services email, TIMA / api.eligibled.com, Discord, LinkedIn, les autres réseaux sociaux, les postes de travail, les réseaux internes, les sites de partenaires et les systèmes appartenant à des tiers.
FULL BAGS, ses exécutables, ses éventuels serveurs de jeu et les autres produits ne sont pas inclus du seul fait qu’ils sont présentés sur le Site. Les dépendances logicielles peuvent faire l’objet d’un signalement contextualisé, mais la présente politique n’autorise pas la recherche sur l’infrastructure de leurs mainteneurs.
En cas de doute sur la propriété ou les limites d’un actif, cessez la vérification et contactez le Studio avant de poursuivre.
4. Bonne foi et proportionnalité
Une démarche de bonne foi vise la découverte et la correction d’un risque, respecte le périmètre convenu, limite les accès au strict nécessaire et n’exploite pas les personnes ou les données rencontrées. La démonstration doit être la moins intrusive possible et s’arrêter dès qu’une preuve suffisante existe.
Ne cherchez pas à augmenter artificiellement l’impact pour obtenir une reconnaissance. Ne maintenez pas un accès après la fin de sa nécessité ou après une demande d’arrêt. Coopérez de façon raisonnable pour préciser le signalement, sans être tenu d’effectuer une action dangereuse ou illicite.
5. Activités interdites
Ne réalisez pas de déni de service ou de test de charge, de saturation d’API, de tentative de force brute ou de contournement du rate limiting. N’utilisez pas les fonctions d’envoi d’email ou de notification pour provoquer des volumes importants ou contacter des tiers.
Sont également exclus : phishing, ingénierie sociale, usurpation, manipulation d’un membre de l’équipe, tests physiques, installation de malware, persistance, portes dérobées, exécution destructive, modification non autorisée de données, suppression, sabotage, déplacement latéral et accès à des comptes de tiers.
Il est interdit d’exfiltrer des bases, des documents, des enregistrements vocaux ou des données personnelles pour démontrer qu’un accès existe. La découverte d’un secret ne permet pas de le réutiliser contre un autre système. L’extorsion, la menace de publication en échange d’un paiement et la vente d’accès ou de données sont incompatibles avec cette politique.
6. Accès accidentel à des données
Si vous rencontrez des données personnelles, des messages, des fichiers de production ou des informations confidentielles qui ne vous sont pas destinés, arrêtez immédiatement l’accès. Ne poursuivez pas l’énumération, n’ouvrez pas d’autres dossiers et ne téléchargez pas des échantillons supplémentaires.
Conservez uniquement les éléments minimaux nécessaires pour localiser l’exposition, par exemple l’URL et un horodatage. Préférez une description expurgée à une capture révélant les personnes concernées. Si une copie s’est constituée involontairement, ne la partagez pas, protégez-la temporairement et convenez avec le Studio de sa suppression dès que possible, sous réserve des obligations légales applicables.
Ne contactez pas directement les personnes dont les données ont été exposées pour démontrer le problème. Le Studio doit évaluer ses obligations de notification et coordonner la réponse à l’incident.
7. Secrets et identifiants exposés
Ne transmettez pas un mot de passe, un jeton complet, une clé privée ou une chaîne de connexion dans l’objet du message, un ticket public ou un dépôt accessible. Indiquez l’emplacement et, si utile, une portion masquée permettant l’identification sans exploitation.
Le Studio peut organiser un canal adapté si la transmission d’un élément sensible est indispensable. Aucune clé de chiffrement ou plateforme de dépôt sécurisé non effectivement mise à disposition n’est promise par cette politique. Une URL publique d’upload ne doit pas être utilisée pour partager une preuve sensible.
8. Contenu attendu d’un rapport
Un rapport exploitable comprend, dans la mesure où ces éléments peuvent être fournis sans risque :
un titre décrivant la faiblesse et le système concerné ;
l’URL ou la fonction touchée, la date, l’heure et le fuseau ;
les prérequis et le niveau d’accès utilisé, en précisant s’il s’agit de votre Compte ;
les étapes minimales de reproduction et le comportement constaté ;
le comportement attendu et l’impact plausible ;
une preuve de concept minimale, expurgée et non destructive ;
les mesures d’arrêt prises et l’existence éventuelle de copies accidentelles ;
un moyen de réponse et votre préférence de reconnaissance publique.
Une proposition de correction ou une référence technique est bienvenue mais n’est pas exigée. Ne joignez pas d’exécutable malveillant. Demandez un mode de transmission avant d’envoyer des fichiers sensibles ou volumineux.
9. Réception et qualification
Le Studio entend examiner les rapports de bonne foi, demander les précisions utiles et apprécier le risque selon l’exploitabilité, les prérequis, les données concernées, l’étendue possible et les conséquences sur la confidentialité, l’intégrité et la disponibilité.
Une sévérité proposée par le chercheur, y compris un score CVSS, est une aide à l’analyse, pas une décision imposée. Les vulnérabilités affectant un composant sont évaluées dans le contexte de leur usage réel ; une simple version de dépendance ne démontre pas toujours une exploitation possible.
Aucun délai ferme d’accusé de réception, de triage ou de correction n’est annoncé sans capacité opérationnelle validée. L’absence d’accusé ne signifie pas que le risque a été accepté. Une relance raisonnable peut être adressée au même contact, en conservant le contexte du rapport.
TODO V01 — Vérifier la surveillance effective de security@noshortcuts.studio, désigner un responsable de triage et un remplaçant, puis décider s’il est possible de publier des objectifs de réponse. Aucun engagement de 24 h, 72 h ou 90 jours n’est inventé.
10. Rapports connus, doublons et demandes non pertinentes
Un problème déjà connu peut être enregistré comme doublon tout en restant utile si le rapport apporte une nouvelle voie d’exploitation ou un impact différent. Le Studio peut expliquer qu’un rapport ne démontre pas de risque exploitable ou relève d’un autre destinataire.
Les messages automatisés répétitifs, les résultats bruts de scanners sans contexte, le spam et les demandes commerciales présentées comme des alertes ne permettent pas une qualification efficace. Un désaccord technique peut être exposé de manière argumentée ; il ne justifie pas une augmentation de l’intrusion ou une menace.
11. Correction et vérification
Les mesures peuvent comprendre une correction de code, une restriction d’accès, une rotation de secret, une modification de configuration ou une intervention auprès d’un fournisseur. Certaines corrections nécessitent de coordonner plusieurs intervenants et peuvent être réalisées par étapes.
La vérification de la correction doit respecter le même périmètre et les mêmes limites. Un nouveau test actif nécessite l’autorisation appropriée ; l’existence d’un signalement antérieur ne crée pas une autorisation permanente. Le Studio ne garantit pas qu’il puisse partager tous les détails de sa réponse, notamment ceux affectant la sécurité ou les droits des tiers.
12. Divulgation coordonnée
Avant toute publication technique, contactez le Studio pour convenir d’un calendrier et d’un contenu qui tiennent compte du risque résiduel, de la disponibilité d’une correction, des dépendances et de la protection des personnes. La coordination ne doit pas servir à imposer indéfiniment le silence sans justification liée à la sécurité.
Une publication responsable exclut les données personnelles, les secrets actifs et les éléments permettant une exploitation disproportionnée d’un système encore vulnérable. La présente politique ne restreint pas les divulgations protégées ou imposées par la loi ni les signalements aux autorités compétentes.
13. Reconnaissance et rémunération
Il n’existe pas de programme de bug bounty annoncé par cette politique. Un rapport, même utile et confirmé, ne crée aucun droit automatique à rémunération. Toute éventuelle récompense nécessite un engagement distinct et explicite du Studio.
Une reconnaissance publique peut être envisagée après accord sur l’identité ou le pseudonyme, le contenu et le calendrier. Aucune identité n’est publiée à cette fin sans accord. Le choix de rester anonyme ne rend pas, à lui seul, le signalement irrecevable.
14. Traitement des signalements de bonne foi — safe harbor limité
Lorsque les actions respectent le droit applicable, l’autorisation écrite requise, le périmètre convenu et les règles de cette politique, le Studio entend les considérer comme une démarche de sécurité de bonne foi. Pour ces seules actions et dans la mesure de ses propres droits, il entend privilégier la coordination et ne pas engager de démarche punitive uniquement en raison du signalement conforme.
Cette position ne constitue ni une immunité pénale, ni une autorisation de porter atteinte à des tiers, ni une renonciation aux droits de personnes autres que le Studio. Le Studio ne peut engager une autorité, un fournisseur ou un titulaire de données. Une autorisation de test ne couvre pas des actions hors de son périmètre.
En cas d’écart ou d’incertitude, le Studio peut demander un arrêt immédiat et examiner les circonstances, la proportionnalité et la coopération. Aucun bénéfice de bonne foi n’est promis pour une extorsion, une exploitation malveillante ou une poursuite volontaire d’accès non autorisés.
15. Confidentialité et données du chercheur
Les coordonnées et informations du rapport servent à qualifier la faille, répondre au chercheur, corriger le problème et, lorsque nécessaire, documenter les incidents ou défendre des droits. L’accès doit être limité aux intervenants utiles ; une transmission à un fournisseur ou à une autorité doit être proportionnée à son objet.
Les modalités d’exercice des droits et les durées encore à formaliser figurent dans la Politique de confidentialité. Ne communiquez pas de données de tiers qui ne sont pas nécessaires au traitement. Une confidentialité absolue ne peut pas être promise en cas d’obligation légale de transmission.
16. Notifications légalement requises
Les échanges avec un chercheur ne remplacent pas les signalements obligatoires aux autorités ni l’information des personnes concernées. Le Studio doit apprécier séparément les obligations applicables à une violation de données, à une vulnérabilité significative d’un logiciel ou à un incident affectant un produit.
TODO V02 — Évaluer le champ du règlement (UE) 2024/2847 (Cyber Resilience Act) pour chaque produit réellement mis à disposition sur le marché de l’Union. Les obligations de notification de son article 14 s’appliquent à partir du 11 septembre 2026 pour les situations et acteurs concernés. Examiner également l’article L. 2321-4-1 du Code de la défense. Le statut pre-alpha ne suffit pas à déterminer à lui seul l’application ou l’exclusion de ces régimes. Les délais de réponse non garantis au chercheur ne suspendent aucun délai légal.
Une évolution du périmètre ou du processus sera publiée avec une date de mise à jour. Une modification ne requalifie pas rétroactivement une recherche réalisée dans le cadre d’une autorisation antérieure applicable. Les Mentions légales identifient l’éditeur et l’hébergeur.