Politique de divulgation responsable

Historique des versions

9 octobre 2026 : ajout de la liste des choix de conception délibérés qui ne sont pas traités comme des vulnérabilités (article 4.3) ; nouvelles autorisations de test réservées aux chercheurs disposant d'un parcours établi (article 5.1) ; précision de ce à quoi exposent les tests sans autorisation (article 5.3).
18 septembre 2026 : ajout des contournements purement côté client au hors périmètre (article 4.2).
1er septembre 2026 : retrait de la désignation d'un délégué à la protection des données, remplacée par un contact protection des données.
29 août 2026 : introduction de l'autorisation préalable obligatoire pour tout test (article 5.1). Les tests antérieurs à cette date relèvent de la version du 4 juin 2026.
4 juin 2026 : version initiale.

1. Introduction

La sécurité de la plateforme Brake Point, et des données télémétrie qui y sont confiées, est une priorité. Cette politique décrit comment signaler une vulnérabilité de manière responsable, ce que nous nous engageons à faire en retour, et la liste des chercheurs ayant contribué à améliorer notre sécurité.

Elle s'applique aux domaines suivants :

www.brakepoint.io (site marketing public)
app.brakepoint.io (application web)
api.brakepoint.io (API REST)
Applications mobiles iOS et Android Brake Point

2. Comment signaler une vulnérabilité

Avant tout test, lisez l'article 5.1 : toute activité de test sur nos systèmes, automatisée ou manuelle, requiert une autorisation écrite préalable, désormais réservée aux chercheurs disposant d'un parcours établi. Le signalement d'une anomalie simplement constatée n'en requiert aucune.

Envoyez un email à security@brakepoint.io avec les éléments suivants :

Description de la vulnérabilité (type, classe OWASP si pertinent)
URL ou endpoint affecté
Étapes de reproduction (proof of concept, requêtes curl, captures d'écran)
Impact estimé (lecture/écriture, données accessibles, prérequis d'authentification)
Vos coordonnées (nom ou pseudonyme à créditer, le cas échéant)

Un fichier /.well-known/security.txt conforme à la RFC 9116 est également disponible.

3. Nos engagements

Accusé de réception dans les 3 jours ouvrés
Évaluation et triage dans les 10 jours ouvrés
Correctif déployé dans un délai conforme à la gravité :
- Critique / Haute : 30 jours
- Moyenne : 60 jours
- Basse : 90 jours
Crédit public sur cette page après déploiement du correctif (ou anonymat si vous le souhaitez)
Pas de poursuite contre les chercheurs respectant cette politique

4. Périmètre

4.1 In-scope

Les catégories ci-dessous définissent ce que nous acceptons comme signalement et ce qu'une autorisation peut couvrir. Elles ne constituent pas une invitation à tester.

Vulnérabilités d'authentification, de session, ou de contrôle d'accès
Injections (SQL, NoSQL, command, template)
Cross-Site Scripting (XSS) avec exécution JavaScript démontrée
Cross-Site Request Forgery (CSRF) sur des actions sensibles (changement de mot de passe, suppression de compte, modifications de paiement)
Server-Side Request Forgery (SSRF), Local/Remote File Inclusion (LFI/RFI)
Insecure Direct Object References (IDOR) permettant l'accès aux données d'un autre utilisateur
Exposition de secrets, clés API, ou identifiants
Élévation de privilèges (PILOT → TRAINER → ADMIN)
Contournement du paiement Stripe ou des limites de quota

4.2 Out-of-scope

En-têtes HTTP manquants sans exploit démontré (CSP, HSTS, X-Frame-Options seuls : utiles, mais signalés en attente d'amélioration interne)
Self-XSS, clickjacking sur pages publiques sans action sensible
Énumération d'utilisateurs sur les endpoints d'inscription / connexion par design (BetterAuth retourne le même statut)
CSRF sur des actions non sensibles (changement de langue, déconnexion)
Open redirects sans impact démontré
Spoofing email contre des sous-domaines sans MX
Vulnérabilités nécessitant un accès physique ou compromission du poste utilisateur
Attaques par déni de service (DoS, DDoS) : ne tentez pas
Vulnérabilités dans des dépendances tierces sans démonstration d'exploit sur notre infrastructure
Findings issus de scans automatisés sans validation manuelle
Vulnérabilités déjà identifiées en interne ou déjà signalées par un tiers (doublons)
Contournements purement côté client sans effet côté serveur, par exemple la modification d'une réponse dans votre propre navigateur pour afficher des pages d'administration dont les API restent refusées
Abus d'envoi de courriels, SMS ou notifications : inondation de boîte de réception, épuisement de quota d'envoi, sollicitation répétée d'un envoi de code. Relève du déni de service et n'est pas à tenter

4.3 Choix de conception qui ne sont pas des vulnérabilités

Une vulnérabilité est un comportement qui permet à quelqu'un de lire, modifier ou détruire des données qui ne sont pas les siennes, d'agir avec des droits qui ne lui ont pas été accordés, ou de dégrader le service pour les autres, et que vous pouvez démontrer. Un écart par rapport à une liste de contrôle, à la note d'un scanner ou à une « bonne pratique », ou un désaccord avec un choix que nous avons fait délibérément, ne constitue pas à lui seul une vulnérabilité.

Les comportements ci-dessous sont délibérés. Nous les connaissons, nous les avons choisis, et nous ne les traitons pas comme des vulnérabilités :

Rôle visible côté client : le rôle renvoyé dans la réponse de session sert uniquement à l'affichage. Chaque requête est autorisée côté serveur, à partir du rôle lu en base de données ; modifier cette valeur dans votre navigateur ne vous donne aucun droit
Code client public : tout ce qui est livré au navigateur ou à l'application mobile est public par nature : noms de routes, code des écrans d'administration, chemins d'API, bundles et manifestes de mise à jour. Les lire n'est pas une fuite d'information
Limites de débit : ce sont des seuils de protection, pas des compteurs exacts. Des requêtes simultanées peuvent dépasser un seuil de quelques unités ; ce n'est pas un contournement
Sessions : la durée de vie des sessions, et la possibilité d'ouvrir plusieurs sessions simultanées sur plusieurs appareils, sont des choix produit. Les sessions sont révoquées côté serveur à la déconnexion et à la réinitialisation du mot de passe
Politique d'authentification : les règles de composition des mots de passe, l'absence d'authentification à deux facteurs, ainsi que le format et la durée de validité des codes envoyés par email
En-têtes de sécurité : le contenu de nos en-têtes, y compris les directives CSP imposées par le framework applicatif, est choisi en connaissance de cause
CORS : l'API accepte les requêtes dépourvues d'en-tête Origin. CORS est un contrôle du navigateur, pas un mécanisme d'authentification ; l'accès aux données repose sur la session
Authentification des emails : le niveau de nos politiques SPF et DMARC

Si vous pouvez démontrer que l'un de ces choix conduit à un impact concret au sens défini ci-dessus, cet impact est dans le périmètre et nous voulons le signalement : décrivez l'impact, pas le choix. Un signalement qui se borne à contester le choix est clos comme informatif, avec une seule réponse. La gravité est appréciée par Brake Point ; un score CVSS attribué par l'auteur du signalement ne nous lie pas.

5. Règles d'engagement

5.1 Autorisation préalable obligatoire

Toute activité de test sur les systèmes Brake Point requiert une autorisation écrite préalable, qu'elle soit automatisée ou manuelle. Cette exigence couvre notamment les tests d'authentification, les tests de contrôle d'accès, les tests de limitation de débit, l'usage de scanners, de proxys d'interception ou d'outils de fuzzing, ainsi que toute création de comptes destinée à conduire des tests.

Les nouvelles autorisations sont restreintes. Près de 100 chercheurs indépendants ont déjà testé la plateforme. Cette couverture est suffisante pour un service de cette taille, et nous n'avons plus la capacité d'encadrer chaque nouvelle demande. Les demandes d'autorisation ne sont désormais examinées que si elles émanent de chercheurs disposant d'un parcours établi et vérifiable, par exemple : vulnérabilités créditées à leur nom (CVE, avis de sécurité d'éditeurs), classement public sur une plateforme de divulgation reconnue, travaux publiés, ou mission conduite pour le compte d'une société de sécurité identifiée.

Pour demander une autorisation, écrivez à security@brakepoint.io en précisant :

votre identité et vos coordonnées
les éléments attestant votre parcours (liens vers les vulnérabilités créditées, profil de plateforme, publications, employeur)
le périmètre visé (domaines, endpoints, fonctionnalités)
les méthodes et outils envisagés
la fenêtre de test souhaitée
les adresses IP sources depuis lesquelles vous opérerez

Nous répondons sous 5 jours ouvrés aux demandes qui établissent un tel parcours. Une demande qui ne l'établit pas est refusée et peut ne pas recevoir de réponse individuelle. L'autorisation est délivrée par écrit ; elle est nominative, limitée dans le temps, limitée au périmètre convenu, et révocable à tout moment.

Signaler n'est pas tester. Le signalement d'une anomalie constatée au cours d'un usage normal du service, sans interaction destinée à en éprouver la sécurité, ne requiert aucune autorisation et reste bienvenu à tout moment via security@brakepoint.io.

Les tests conduits sans autorisation préalable sortent du cadre de la présente politique. L'article 5.3 précise ce à quoi ils exposent leur auteur.

5.2 Conditions applicables à une autorisation délivrée

Dans le cadre d'une autorisation accordée, les chercheurs s'engagent à :

Ne pas perturber le service ni dégrader l'expérience des autres utilisateurs
Ne pas accéder, modifier ou supprimer des données ne vous appartenant pas ; utilisez les comptes de test convenus dans l'autorisation
Ne pas pratiquer d'ingénierie sociale envers nos employés, prestataires ou utilisateurs
Ne pas tester contre l'infrastructure Stripe, Brevo ou Scaleway au-delà des endpoints publics de Brake Point
Ne pas divulguer publiquement la vulnérabilité avant le déploiement du correctif (coordination requise, 90 jours par défaut)
Rester dans le périmètre, la fenêtre et le volume fixés par l'autorisation ; à défaut de volume convenu, ne pas dépasser 5 requêtes par seconde en régime soutenu
Communiquer les comptes créés pour les besoins du test, afin que nous puissions les supprimer

5.3 Tests sans autorisation

Brake Point ne consent à aucun test de sécurité de ses systèmes réalisé sans l'autorisation écrite préalable prévue à l'article 5.1. Un tel test est également interdit par nos Conditions générales d'utilisation (article 5.2).

Avant de tester sans autorisation, sachez ce qui suit :

Le terrain est déjà couvert. Près de 100 chercheurs ont déjà testé la plateforme. Ce qu'un premier passage fait ressortir (seuils de limitation de débit, rôle visible côté client, contenu des en-têtes, réponses à l'inscription) nous est connu et figure aux articles 4.2 et 4.3 : ces signalements sont clos sans crédit
Cela ne rapporte rien. Nous ne versons aucune prime. Les découvertes issues de tests non autorisés ne donnent lieu ni à récompense ni à crédit public (article 6)
C'est hors du cadre de cette politique. Ces tests ne bénéficient d'aucun des engagements de l'article 3, y compris l'absence de poursuite
C'est journalisé. Les requêtes d'authentification, et les tentatives d'accès refusées faute de droits, sont enregistrées avec leur adresse IP source
Votre compte peut être fermé. L'article 5.3 des Conditions générales d'utilisation nous permet de suspendre ou de résilier définitivement un compte utilisé à cette fin
Le droit pénal français s'applique où que vous soyez. Le fait d'accéder ou de se maintenir frauduleusement dans tout ou partie d'un système de traitement automatisé de données est puni de trois ans d'emprisonnement et de 100 000 € d'amende (article 323-1 du code pénal), et le fait d'en entraver ou d'en fausser le fonctionnement de cinq ans d'emprisonnement et de 150 000 € d'amende (article 323-2). La tentative est punie des mêmes peines (article 323-7). Un délit réalisé au moyen d'un réseau de communication électronique au préjudice d'une personne morale dont le siège se situe en France est réputé commis en France (article 113-2-1)
Nous pouvons y donner suite. Nous nous réservons le droit de signaler tout test non autorisé aux autorités compétentes et de demander réparation du préjudice qu'il aurait causé

Rien de ce qui précède ne concerne le signalement d'une anomalie constatée au cours d'un usage normal du service, qui reste bienvenu (article 5.1).

6. Récompenses

Brake Point ne propose pas de programme de bug bounty rémunéré à ce stade. Nous offrons :

Crédit public sur cette page (avec lien et catégorie de vulnérabilité)
Remerciements nominatifs dans le commit de correctif et le CHANGELOG
Goodies Brake Point (stickers, t-shirt) pour les contributions notables, sur demande, dans la limite des stocks
Pour des contributions exceptionnelles : accès gratuit longue durée au plan Pro

Ne sont pas éligibles au crédit public ni aux contreparties ci-dessus :

les signalements portant sur une vulnérabilité déjà identifiée en interne avant réception du signalement, ou déjà signalée par un tiers
les signalements hors périmètre (article 4.2)
les signalements qui se bornent à contester un choix de conception documenté (article 4.3)
les découvertes issues de tests conduits sans autorisation préalable (article 5.1)
les signalements dont l'impact n'est pas démontré

L'éligibilité est appréciée par Brake Point. Un signalement non éligible reste traité et corrigé selon les délais de l'article 3 lorsqu'il est fondé ; seule la contrepartie est exclue.

Cette politique pourra évoluer vers un programme rémunéré après le lancement officiel (fin novembre 2026).

7. Remerciements

Nous remercions publiquement les chercheurs ayant contribué à améliorer la sécurité de Brake Point :

Chercheur	Vulnérabilité	Signalé le	Corrigé le
rae050	Élévation de privilèges	7 août 2026	10 août 2026

8. Contact

Signalement de vulnérabilité : security@brakepoint.io

Contact protection des données : privacy@brakepoint.io

Adresse postale :

Ethan Consulting
10 allées des boutons d'or
78180 Montigny-le-Bretonneux
France