Divulgation responsable des vulnérabilités
Tout logiciel a des bugs. Les nôtres, on préfère que ce soit vous qui les trouviez.
Voici le programme de divulgation des vulnérabilités d'diagnos. Nous ne payons pas en argent — aujourd'hui, nous n'en avons pas les moyens. Nous payons en gratitude publique, en une place au hall of fame et en la certitude que l'examen de quelqu'un est devenu plus sûr grâce à votre contribution.
curl https://diagnos.health/.well-known/security.txt Contact: mailto:[email protected]Contact: mailto:[email protected]Policy: https://diagnos.health/en/bounty/Preferred-Languages: pt-BR, en, es, it, frExpires: 2027-09-16T00:00:00Z Accès rapide
Les dix sections de cette page, pour ouvrir directement celle qu'il vous faut.
Hall of fame
Toute vulnérabilité valide atterrit dans cette liste, sous le nom que vous choisissez — votre nom, votre pseudo, votre @, ou aucun des trois.
| # | Chercheur | Ce qu'il a trouvé | Quand |
|---|---|---|---|
| 001 | VOUS | cette ligne est réservée | quand vous voulez |
| 002 | — | — | — |
| 003 | — | — | — |
| 004 | — | — | — |
| 005 | — | — | — |
J'AI BESOIN DE VOUS
POUR LA SÉCURITÉ D'DIAGNOS
Posture de sécurité
Contrôles actifs en production
-
Votre mot de passe ne nous arrive jamais
La connexion tourne sur OPAQUE, un PAKE : le serveur ne voit jamais votre mot de passe, même pas pendant la connexion. Il ne garde qu'un registration_record, inutile tout seul.
-
Le serveur ne peut pas ouvrir votre coffre
Les clés naissent sur votre appareil. Le serveur ne reçoit que du texte chiffré — aucune ligne de code, de l'autre côté, n'ouvre une KEK.
-
Rejouer une requête ne marche pas
Chaque requête sensible porte un nonce + un timestamp, clé primaire (scope_id, ts, nonce) dans D1, une tolérance d'horloge de 120s et une rétention de 300s balayée par un cron.
-
Chaque requête pertinente devient une trace
On écrit un objet par requête pertinente dans R2. L'écriture est facturée et tourne hors du chemin critique de la réponse — auditer ne ralentit personne.
-
Le domaine le plus sensible est le plus verrouillé
sign.diagnos.health applique une CSP default-src 'none' pour de vrai — elle bloque, elle ne se contente pas de signaler — avec un SRI calculé au build. Le cookie d'appareil est __Host-, HttpOnly, Secure, SameSite=Strict.
-
La donnée clinique sait où elle habite
Comptes rendus et images vivent dans un bucket R2 dont la juridiction UE est attachée directement au binding — pas une promesse contractuelle, un réglage que l'infrastructure applique.
Lacunes connues
- On n'a jamais engagé de test d'intrusion indépendant. Personne de l'extérieur n'a audité ça.
- Pas de SOC 2, pas d'ISO 27001.
- HIPAA : les exigences techniques sont couvertes, mais la chaîne de contrats avec les sous-traitants (BAA) est incomplète — deux signés seulement, le reste en négociation.
- La CSP de l'application est encore en mode report-only : elle signale la violation, elle ne bloque rien.
- Le scan automatisé de vulnérabilités reste ponctuel, pas une routine continue.
- Le disjoncteur du rate limit est une estimation prudente, jamais calibrée sur du trafic réel de production.
La première liste, c'est ce qu'on a déjà construit. La seconde, c'est pourquoi cette page existe. On ne vous demande pas votre confiance — on vous demande votre méfiance, noir sur blanc dans un rapport.
Périmètre du programme
Neuf cibles possibles. L'étiquette à côté de chacune dit si elle est dans, hors, ou dans-mais-avec-un-astérisque — lisez-la avant de pointer un outil vers l'une d'elles.
| Cible | Statut | Ce que c'est |
|---|---|---|
| vault.diagnos.health | Dans le périmètre | Le serveur principal du produit — le « coffre ». Session, déverrouillage via OPAQUE, le ledger, les URL signées de R2, les Agents IA, le MCP et l'OAuth passent tous par ici. |
| api.diagnos.health | Dans le périmètre | Le même serveur, sous l'autre nom que le produit utilise pour lui. Aujourd'hui, les deux entrées cohabitent dans le code — les deux sont valables. |
| /api/internal/v1/* | Dans le périmètre, avec réserve | Un préfixe à l'intérieur de l'API elle-même, réservé à l'application officielle — il exige des en-têtes qu'un curl tout seul ne produit pas. Lisez la note ci-dessous avant de tester cette ligne. |
| sign.diagnos.health | Dans le périmètre | La cérémonie de signature du compte-rendu — WebAuthn/clé d'accès, atteinte par lien ou code QR. Le domaine le plus sensible du produit. |
| app.diagnos.health | Dans le périmètre | L'application web d'diagnos. |
| diagnos.health | Dans le périmètre | Ce site, celui que vous lisez en ce moment. Il est dans le périmètre même s'il s'agit de marketing statique — mais ajustez vos attentes : le pire qu'on puisse y trouver, c'est une redirection ouverte. |
| SDK · CLI · API Apache-2.0 | Dans le périmètre | SDK, CLI et API en Python, sous licence Apache-2.0. Le code rejoindra bientôt un dépôt public — le lire est bienvenu. |
| *.diagnos.health | Hors périmètre | Tout *.diagnos.health absent de cette liste est hors périmètre et hors du safe harbor. C'est la norme popularisée par GitHub : nous ne pouvons autoriser la recherche que sur les systèmes qui nous appartiennent. |
| cloudflare · google · modal · sentry · … | Hors périmètre | Cloudflare, Google/Firebase, Modal, Sentry et consorts. Signalez-le-leur, pas à nous — sauf si le problème vient clairement de notre intégration. |
À propos de l'audience « internal » (et pourquoi curl seul n'y arrive pas)
En-têtes exigés
L'audience internal exige, tous à la fois :
Authorization: Bearer <Firebase ID token>X-AppCheck-TokenX-Signature-HmacX-Signature-NonceX-Signature-Timestamp
Ce qui n'existe pas
- X-Device-Challenge n'existe pas. Le nom a circulé en interne, mais il n'y a jamais eu une seule ligne de code avec ce nom.
- Il n'existe pas de verrouillage automatique de l'espace de travail. Aucun appel erroné ne bloque un compte tout seul — ça aussi, ça a circulé, et c'est tout aussi faux.
Ce qui existe vraiment
Ce qui existe vraiment, et qui dit la même chose :
- Une limite de requêtes par route, plus un disjoncteur par périmètre : 600 requêtes par fenêtre.
- Une vraie protection anti-rejeu : clé primaire (scope_id, ts, nonce) — un nonce répété renvoie 409, pas 401.
- Un frein anti force brute sur la connexion : 10 tentatives en 15 minutes par compte, en meilleur effort.
- Chaque 4xx/5xx devient un signal de sécurité anonyme ; ceux de gravité élevée ouvrent une exception qu'une personne examine avant tout blocage.
Testez l'audience internal via l'application web, avec votre propre compte : les en-têtes naissent naturellement, et tout ce que vous y ferez est dans le périmètre et couvert par le safe harbor. Marteler /api/internal/v1/* directement en curl ne prouve rien de plus qu'une collection de 401 — et ça génère surtout du bruit qu'une personne devra trier à la main.
Données patients
Ce qu'il ne faut pas faire
- N'ouvrez pas l'examen.
- Ne faites pas défiler la page.
- Ne prenez pas de capture d'écran.
- Ne copiez pas l'ID « pour vérifier plus tard ».
Ce qu'il faut faire
- Signalez-le tout de suite, avec le minimum de détails nécessaires pour prouver que le problème existe.
- La preuve de concept démontre l'accès, jamais le contenu — par exemple : « j'ai pu lister les dossiers d'autres espaces de travail via le endpoint X en changeant le paramètre Y », sans coller le compte-rendu.
- Supprimez toute copie locale : cache, captures d'écran, historique Burp, journaux de proxy.
- N'exfiltrez, ne téléchargez, ne partagez, ne publiez et n'essayez jamais de monétiser une donnée patient — même pour prouver l'impact.
Fondement juridique
Une donnée de santé est une donnée personnelle sensible au sens de la LGPD, la loi brésilienne de protection des données (art. 5, II combiné à l'art. 11).
Et le §4 de l'art. 154-A du Code pénal brésilien augmente la peine d'1/3 à 2/3 en cas de divulgation, de commercialisation ou de transmission à un tiers des données obtenues — même lorsque l'accès initial était autorisé. Autrement dit : le safe harbor de cette politique couvre le fait d'être entré ; il ne couvre pas le fait d'être reparti avec quelque chose.
Tem uma consequência que é sua, não só nossa: quem decide o que fazer com o dado é, por definição, o controlador dele. Se você baixar, guardar ou compartilhar o que achou, você deixa de ser alguém testando o sistema e vira isso sozinho — respondendo direto perante o titular nos termos dos dois regimes, sem cobertura nenhuma desta política. E tirar esse dado do bucket europeu para qualquer outro lugar também é transferência internacional de dado pessoal, com regime próprio nos dois lados: LGPD, arts. 33 a 36; GDPR, Capítulo V, arts. 44 a 49.
E se o que você achou não é uma falha em potencial, mas exposição que já aconteceu, o seu relatório é o que dispara, para nós, o prazo legal de notificar a autoridade e o titular — até 72 horas pelo GDPR (Art. 33), até 3 dias úteis pela LGPD (Resolução CD/ANPD nº 15/2024). É por isso que pedimos para reportar na hora, em vez de continuar investigando atrás de um achado mais completo.
Ce n'est pas de la bureaucratie. C'est que de l'autre côté de ce JSON, il y a un résultat de biopsie avec un nom et un prénom.
Règles de participation
Pendant le test
- Tester avec vos propres comptes de test, ou des comptes que vous avez créés vous-même.
- Utiliser un outil automatisé — scanner, fuzzer — avec bon sens.
- Vous arrêter au premier signe de donnée réelle de patient et le signaler.
- Accéder, ou tenter d'accéder, au compte de quelqu'un d'autre.
- Faire un DoS volumétrique, ou lancer un scanner qui envoie des milliers de requêtes par minute contre la production — déverser du trafic n'est pas de la recherche, c'est de l'abus.
- Faire de l'ingénierie sociale contre notre équipe, nos patients ou nos partenaires.
- Mener une attaque physique.
S'arrêter n'est pas une suggestion — c'est la règle la plus importante de cette page. Le détail complet est dans Données patients.
Usage de l'IA dans les rapports
- Utiliser l'IA pour explorer ou rédiger, très bien — on ne va pas faire comme si ça n'existait pas. Mais vous répondez de chaque mot et de chaque affirmation technique du rapport, généré par IA ou non.
- Dites explicitement si un outil d'IA a aidé.
- Chaque rapport a besoin d'une preuve de concept qui fonctionne vraiment, reproduite par vous. Une sortie de scanner ou de LLM sans confirmation manuelle n'est pas une vulnérabilité — c'est une hypothèse, et une hypothèse non vérifiée est classée invalide.
Un rapport fabriqué, exagéré ou dont la PoC ne se reproduit pas est classé sans réponse détaillée. La récidive entraîne le bannissement du programme.
En janvier 2026, le projet curl a fermé l'intégralité de son programme de bug bounty après que les rapports générés par IA se sont mis à largement dépasser les rapports valides. En des années de suivi, aucun rapport produit uniquement par IA, sans vérification humaine, n'a jamais trouvé de vulnérabilité réelle.
On préfère ne pas en arriver là.
Délais de traitement
-
Accusé de réception
Nous confirmons la réception de votre rapport sous 5 jours ouvrés.
-
Tri
Nous évaluons la sévérité et vous disons vers où ça va.
-
Correction
Nous travaillons sur le correctif avec une priorité proportionnelle à la sévérité.
-
Notification
Nous vous prévenons dès que le correctif est publié.
-
Reconnaissance
Nous proposons un crédit public facultatif — et nous ne représaillons jamais une recherche de bonne foi.
L'échelle complète de sévérité et de priorité est dans la section Classification de sévérité.
Divulgation publique
Nous demandons 90 jours calendaires comptés à partir de la confirmation du problème — pas de l'envoi, une date que vous seul contrôlez — avant toute publication.
Si le correctif sort avant, on peut convenir d'une date de divulgation conjointe plus tôt.
Si le problème est activement exploité par un tiers en ce moment, ce délai se réduit — prévenez-nous immédiatement.
Et ne publiez jamais de donnée patient, d'identifiant réel, ni quoi que ce soit qui augmente le risque, même après le délai.
Safe harbor juridique
Concrètement, nous nous engageons à :
- Ne pas engager ni soutenir d'action civile, de plainte pénale ou de signalement à la police contre vous pour une recherche menée dans le cadre de cette politique — y compris pour toute mesure technique utilisée pour accéder à un système dans le périmètre.
- Si un tiers vous menace ou engage une action en justice à cause de cette recherche, déclarer publiquement et formellement que votre conduite était une recherche de sécurité autorisée et de bonne foi.
Et cela a des limites, aussi visibles que la promesse :
- Ça ne couvre que les systèmes listés dans Périmètre. Nous ne pouvons pas autoriser de recherche sur un système tiers, même accessible depuis le nôtre.
- Ça ne couvre pas une conduite hors périmètre ou hors des règles de cette politique.
- Ça ne couvre pas le fait d'emporter des données. Accéder pour tester est une chose ; extraire en est une autre — voir Données patients et le §4 de l'art. 154-A, qui aggrave justement la peine pour ça.
- Ça ne s'applique pas à une recherche menée pour extorquer ou contraindre quelqu'un, ni à qui est exclu dans Reconnaissance.
Vous nous testez depuis l'étranger ? Cette autorisation reste fondée sur le droit brésilien — c'est lui qui régit les systèmes que vous toucheriez. Par courtoisie, nous considérons aussi cette politique comme une autorisation d'accès de bonne foi au regard du droit de la cybercriminalité applicable dans votre pays.
Vous n'êtes pas sûr qu'un test précis rentre dans cette politique ? Demandez-nous d'abord, à [email protected].
Fondement juridique au Brésil
Au Brésil, il n'existe ni "CFAA" ni "DMCA". Ce sont des lois américaines, et coller ce sigle dans une politique brésilienne ne protège personne ici — ça trahit juste un texte traduit, pas pensé.
Ce qui s'applique, c'est l'art. 154-A du Code pénal brésilien (loi n° 12.737/2012, modifiée par la loi n° 14.155/2021). Il fait de l'intrusion dans un dispositif informatique d'autrui "sans autorisation expresse ou tacite" de son utilisateur un délit.
Un détail change tout. Le texte de 2012 ne s'appliquait que si l'intrusion se faisait "par violation indue d'un mécanisme de sécurité" — il fallait casser une protection. La loi n° 14.155/2021 a supprimé cette exigence. Aujourd'hui, le délit ne dépend plus de casser quoi que ce soit : il dépend seulement d'agir sans autorisation. L'autorisation est devenue le seul élément décisif.
C'est pour ça que cette page est l'autorisation expresse dont parle la loi. Et c'est plus solide qu'une promesse de ne pas vous poursuivre : avec autorisation, le délit n'existe tout simplement jamais — ce n'est pas une défense après coup, c'est l'absence d'un élément de l'infraction elle-même. Une conduite autorisée ne devient jamais un délit.
Rapports non éligibles
Ce n'est pas qu'on s'en moque — c'est que sans impact démontré, impossible de le distinguer du bruit de fond.
Configuration et en-têtes
- En-tête de sécurité manquant (CSP, HSTS, X-Frame-Options) sans PoC d'exploitation réelle.
- Enregistrement SPF, DKIM ou DMARC manquant ou mal configuré.
- Divulgation de version logicielle dans une bannière, un en-tête ou un changelog public, sans exploitation associée.
- Absence de certificate pinning dans une application mobile.
Interface et interaction
- Clickjacking sur une page qui n'exécute aucune action sensible.
- Self-XSS — la victime doit coller elle-même le payload.
- Redirection ouverte sans impact supplémentaire démontré.
Énumération et limites de débit
- Énumération d'utilisateur ou d'e-mail — découvrir si un compte existe.
- Absence de limitation de débit sans preuve d'un brute-force viable.
- Injection CSV sans exécution prouvée dans l'environnement de la victime.
Infrastructure et disponibilité
- Déni de service volumétrique, ou tout ce qui dépend de la génération d'un trafic massif.
- Une attaque qui exige d'intercepter le trafic de quelqu'un d'autre, sans une faille de notre côté qui le permette.
Tiers et dépendances
- Une faille dans une bibliothèque tierce, sans PoC d'exploitation spécifique dans notre environnement.
- Une faille dans un service ou une infrastructure que nous n'exploitons pas.
Qualité du rapport
- Sortie d'un scanner sans PoC manuelle et sans confirmation d'exploitation réelle.
- Rapport généré par IA sans vérification humaine et sans PoC reproductible.
Hors du modèle de menace
- Ingénierie sociale contre notre équipe, nos partenaires ou nos patients.
- Attaques physiques contre un bureau, un employé ou un appareil.
- Un bug qui n'apparaît que sur un navigateur ou un système d'exploitation obsolète, sans support du fabricant.
- Une attaque qui dépend du fait que la victime suive les instructions de l'attaquant lui-même — coller une commande, installer une extension.
Vous pensez que votre cas est l'exception ? Envoyez-le quand même et expliquez pourquoi. Cette liste est un filtre, pas un mur.
Classification de sévérité
La sévérité décide d'une seule chose : l'ordre de la file de correction. Rien d'autre.
| Sévérité | Critère général | Exemples chez diagnos |
|---|---|---|
| Critique | Compromet la confidentialité de plus d'un patient, ou brise la garantie centrale du chiffrement de bout en bout — sans que la victime ait besoin de cliquer sur quoi que ce soit. |
|
| Élevée | Compromet les données d'un seul workspace, ou donne un privilège d'administrateur à l'intérieur — toujours sans interaction de la victime. |
|
| Moyenne | A un impact réel, mais limité : exige un clic de la victime, ou expose des métadonnées plutôt que le contenu du compte-rendu. |
|
| Faible | Impact minime, exige des conditions improbables réunies, ou n'est qu'informatif — sans chemin clair vers une donnée patient. |
|
Le classement final nous appartient — mais on explique le raisonnement. Si vous n'êtes pas d'accord, dites-le : on réévalue.
Reconnaissance et éligibilité
Quatre choses, dans cet ordre — la première pique un peu.
-
De l'argent : zéro.
Pas de "on étudie la question". Zéro, vraiment. Nous sommes une petite entreprise, et l'argent qui existe paie le serveur et les salaires. Si ça change un jour, cette page change avec — et vous serez parmi les premiers informés.
-
Un crédit produit, peut-être.
Nous pouvons — à notre discrétion et sans aucune obligation — offrir un crédit d'utilisation de la plateforme. Sans valeur convenue, sans garantie, non négociable. Ce n'est pas un paiement : c'est de la gratitude avec une facture autour.
-
Une place au hall of fame.
Toute vulnérabilité valide y entre — sous le nom que vous choisissez : votre vrai nom, un pseudo, un @ de réseau social, ou anonyme.
Voir le hall of fame -
La gratitude de gens que vous ne connaîtrez jamais.
De l'autre côté, il y a des médecins et des patients qui ne sauront jamais votre nom. C'est peu. On le sait. Mais c'est vrai.
Et on vous demande une chose en retour : la permission de citer votre rapport — technique, sans donnée patient — dans notre changelog de sécurité, une fois le correctif publié.
Qui peut participer
N'importe qui peut signaler une faille, et on la corrige de toute façon. Ce qui change, c'est la reconnaissance — pas de mention publique ni de crédit produit pour :
- Quiconque travaille ou a travaillé chez MedDeck au cours des six derniers mois — prestataires inclus.
- Un proche direct de quelqu'un ayant une information privilégiée sur le système testé.
- Une personne ou entité sur une liste de sanctions (OFAC/SDN, Union européenne) ou dans un pays sous embargo général.
- Quiconque a atteint la faille par rupture de contrat ou fuite interne, plutôt que par une recherche indépendante.
Comment envoyer un rapport
La plupart des signalements arrivent dans la boîte standard. L'autre existe pour quand attendre coûterait vraiment cher.
Le canal standard
Tout signalement arrive ici — c'est la boîte que nous lisons en premier, toujours.
Envoyer un signalementSeulement quand attendre coûte cher
Exploitation active en cours en ce moment. Données d'un patient déjà exposées publiquement. Un identifiant qui a fuité. Cette boîte est pour ça — et rien que pour ça.
Ça ne peut pas attendre Ce que le signalement doit contenir
- Des étapes de reproduction numérotées, dans l'ordre où vous les avez vraiment suivies.
- L'impact réel — ce qu'un attaquant peut FAIRE, pas juste "j'ai obtenu X".
- L'environnement, le navigateur et le compte utilisés.
- Une preuve de concept minimale et non destructive.
Pas besoin que ce soit en anglais, ni mis en forme comme un CVE. La clarté compte plus que le formalisme.
Gardez tout sur le canal privé avec nous jusqu'à ce qu'on s'accorde ensemble sur la divulgation publique.
Le fichier qui fait ce travail à votre place. Il est déjà en ligne, et c'est par lui qu'un outil automatique nous trouve avant qu'un humain ne lise ceci : /.well-known/security.txt
Signalement chiffré
Nous n'avons pas encore publié de clé PGP. Vous voulez chiffrer quand même ? Demandez-nous par e-mail, on vous envoie comment faire.
Questions fréquentes
Vous ne payez vraiment rien ?
Rien. Ni argent, ni crypto, ni t-shirt. On peut proposer un crédit produit quand ça a du sens, sans aucune garantie — c'est de la gratitude avec une limite, pas un prix déguisé.
Puis-je tester avec mon vrai compte ?
Oui, et c'est la méthode recommandée si vous faites partie du public interne — voir la section « Périmètre ». Ce que vous ne pouvez jamais faire, en aucun cas, c'est tester avec le compte de quelqu'un d'autre.
J'ai trouvé des données de patient. Et maintenant ?
Arrêtez-vous. N'ouvrez pas l'examen, ne faites pas défiler, ne copiez pas l'ID « pour confirmer plus tard ». Signalez la découverte sans coller le contenu du compte rendu — la section « Données patients » donne la marche à suivre, et ce n'est pas de la paperasse : c'est ce qui sépare la recherche de sécurité du délit.
Combien de temps avant qu'on me réponde ?
Nous confirmons la réception sous 5 jours ouvrés ; ensuite, vous recevez une position sur la gravité et la suite. C'est un objectif de service qu'on s'impose, pas une clause de SLA contractuelle.
Puis-je publier ce que j'ai trouvé ?
Oui — 90 jours calendaires après la confirmation du problème, ou avant si on convient d'une date ensemble. Jamais avec des données de patient dedans, même après ce délai.
J'ai utilisé l'IA pour trouver ça. C'est un problème ?
Aucun, du moment que vous avez vérifié et reproduit le problème vous-même, dans un environnement réel. Une sortie d'IA sans cette vérification n'est pas une vulnérabilité, c'est une hypothèse — la section « Règles » explique pourquoi.
Vous allez me poursuivre ?
Non, si vous avez suivi cette politique. La section « Safe harbor » est, en une phrase, l'autorisation expresse que l'art. 154-A du Code pénal brésilien exige pour que ce que vous vous apprêtez à faire ne soit pas un délit — ce n'est pas de la rhétorique, c'est le texte de la loi.
J'ai déjà signalé et je n'ai pas eu de réponse.
Renvoyez en mentionnant la date du premier envoi — un e-mail se perd. Si c'est vraiment urgent, utilisez la boîte d'urgence. Ce n'est pas du mépris : nous sommes une petite équipe, pas un centre d'opérations de sécurité 24 heures sur 24.
C'est tout. Allez-y.
Si vous avez lu jusqu'ici, vous tenez déjà aux données de ces patients plus que bien des gens dont c'est le métier. Merci — et bonne chasse.
Signaler une faille