Tests de sécurité réalisés en interne #
Il s’agit de tests réalisés en interne. Ils sont menés par l’opérateur et non par un évaluateur indépendant, et ils ne remplacent pas le test d’intrusion externe indépendant indiqué sur Trust. Ils sont publiés parce que leur contenu est utile à la personne qui les examine, même en l’absence d’indépendance.
Dernière mise à jour : 2026-10-18.
Tests réalisés #
| Date | Type | Périmètre | Résultat |
|---|---|---|---|
| 2026-05-26 | Évaluation de sécurité au niveau du code | Analyse statique, audit des dépendances et revue manuelle de l’authentification, de l’autorisation et du traitement des fichiers | Le traitement des téléversements a été identifié comme le domaine le plus à risque. Constats suivis dans le gestionnaire de tickets et corrigés : limitation du nombre de pièces jointes côté serveur, autorisation des téléversements directs, et nettoyage des paramètres et des adresses IP dans les journaux |
| 2026-05-26 | Test externe en production, non destructif | En-têtes de réponse, configuration TLS, pages publiques et sondes de métadonnées sur l’hôte de production | Lacunes dans la couverture des en-têtes de réponse et absence de métadonnées de contact sécurité ; la dépendance à des CDN d’actifs tiers a été évaluée comme un risque moyen. Corrigé le 2026-05-27 : métadonnées de contact sécurité publiées, protection contre le sniffing de type de contenu étendue aux actifs statiques |
| 2026-06-09 | Revue de l’authentification | Gestion des cookies, cycle de vie des sessions, parcours de lien magique et d’invitation | Deux constats de gravité informative. Corrigés le 2026-06-14 : le cookie d’authentification en attente est désormais placé dans un magasin chiffré, de sorte que l’adresse n’est plus lisible côté client ; l’expiration annoncée du cookie de session correspond désormais au délai d’inactivité serveur de 14 jours. Un constat de faible gravité : les adresses des dispositifs d’alerte étaient dérivées d’identifiants séquentiels, ce qui permettait d’énumérer l’ensemble des organisations clientes. Corrigé le 2026-08-12 : chaque dispositif d’alerte dispose d’une adresse privée aléatoire, et la page affichée pour un dispositif d’alerte inactif ne nomme plus l’organisation |
| 2026-08-27 | Test en graybox authentifié | Accès inter-locataires, élévation de privilèges, affectation de masse, accès aux signalements au sein d’un même locataire, confidentialité des pièces jointes, isolation SCIM, confiance dans les assertions SAML | Aucun défaut d’autorisation constaté. Les frontières de locataire et de rôle ont tenu dans tous les cas testés |
| 2026-08-27 | Revue de l’exposition en production | Exposition réseau, durcissement de l’hôte, traitement des en-têtes de proxy, gestion des secrets | Les en-têtes de transfert fournis par le client étaient considérés comme fiables sur une origine directement exposée à Internet, ce qui aurait permis de contourner les limitations de débit par IP. Corrigé le jour même. Un en-tête indiquant le temps de traitement serveur par requête a également été retiré. L’en-tête obsolète Feature-Policy a été remplacé par Permissions-Policy le 2026-09-05 |
| 2026-09-08 | Revue authentifiée de la mise à disposition des fichiers et de leur conservation par le navigateur | Téléchargement direct des exportations de données et des enregistrements vocaux, accès avec des URL de fichiers connues entre locataires et après le retrait d’un membre, bouton Retour du navigateur après la déconnexion | Trois constats, chacun nécessitant un utilisateur déjà autorisé et détenteur d’une URL de fichier signée, ou un navigateur partagé. Une exportation de données expirée pouvait encore être téléchargée à partir d’une URL conservée, sans nouvelle authentification. Une personne chargée du traitement pouvait télécharger un enregistrement vocal original avant la fin de son anonymisation. Après la révocation d’une session, le bouton Retour du navigateur pouvait réafficher un signalement depuis son cache. Corrigés le 2026-09-10 : la mise à disposition des fichiers applique désormais les mêmes règles d’expiration, de réauthentification et de traitement que la page qui y renvoie, et les pages sensibles et les fichiers privés ne sont plus conservés par le navigateur. L’accès entre locataires et l’accès par un membre retiré ont été refusés dans tous les cas testés |
| 2026-09-26 | Revue de la gestion des sessions au niveau du code | Identification des sessions et leur comportement après une restauration de la base de données | Les sessions étaient identifiées par leur identifiant en base de données. Une restauration ramène les identifiants en arrière, de sorte qu’une nouvelle connexion pouvait recevoir un identifiant encore détenu par un cookie subsistant et reprendre la session de cet utilisateur. Corrigé le jour même : les sessions sont identifiées par un jeton aléatoire, et toutes les sessions existantes ont été clôturées |
| 2026-09-28 | Revue des journaux du dispositif d’alerte | Journaux côté application écrits pendant qu’un lanceur d’alerte utilise le dispositif d’alerte | Deux composants enregistraient encore les adresses IP des lanceurs d’alerte : le journal des requêtes du serveur web et l’avertissement de la protection anti-spam. Cet enregistrement a été supprimé dans les deux cas le jour même. Le journal des requêtes propre au proxy TLS, qui enregistre l’adresse IP de chaque requête, est inchangé et décrit sur Security#ip-addresses |
| 2026-10-16 | Revue au niveau du code au regard des recherches actuelles sur les attaques visant Rails | Traitement des téléversements, décodage des images, traitement des messages signés, journaux des requêtes, messages temps réel stockés, code d’autorisation généré | La suppression des métadonnées choisissait sa méthode d’après le type déclaré par le navigateur, de sorte qu’une photo téléversée comme fichier générique conservait ses métadonnées de localisation et d’appareil. Le décodeur SVG de la bibliothèque d’images, bloqué au démarrage, était réactivé pour l’ensemble du processus dès qu’une image d’aperçu de lien avait été générée. Les messages signés et chiffrés acceptaient encore un format de sérialisation qui transforme la fuite d’un secret de l’application en exécution de code. Les journaux des requêtes enregistraient les noms de fichier des pièces jointes et des jetons de téléchargement à courte durée de vie. Les notifications en temps réel, qui contiennent le code d’accès au signalement, étaient stockées sans chiffrement pendant une journée. Le modèle des nouvelles politiques d’autorisation omettait le filtre par organisation ; aucune politique existante n’était concernée. Tous corrigés le jour même |
| 2026-10-16 | Contrôle forensique en production (CVE-2026-66066) | Inspection en lecture seule de chaque fichier stocké avant le correctif, à la recherche d’en-têtes d’image forgés, d’images dont les pixels se décodent en fichiers du serveur et de métadonnées d’identification résiduelles | Aucune preuve d’exploitation dans les données conservées, et aucune image de signalement portant encore des métadonnées d’identification. Les fichiers susceptibles d’avoir été téléversés par le chemin de téléversement direct exposé, ouvert du 2026-04-13 au 2026-05-12, ont été purgés par le nettoyage quotidien des fichiers non rattachés et ne peuvent plus être examinés |
| 2026-10-17 | Revue de l’exposition en production | Journal des requêtes du proxy inverse, limites de taille des requêtes, analyse des vulnérabilités de l’image de conteneur | Le proxy inverse journalise le chemin de chaque requête, et les chemins de téléchargement des pièces jointes contenaient le nom du fichier. Les corps de requête jusqu’à 1 Go étaient mis en mémoire tampon sur disque avant que l’application ne les valide. L’image de conteneur faisait l’objet d’une analyse mensuelle des vulnérabilités du système d’exploitation, face à un engagement de 7 jours pour les correctifs critiques. Corrigés le jour même : aucune des deux étapes du téléchargement d’une pièce jointe ne contient le nom du fichier dans son chemin, les corps de requête sont plafonnés juste au-dessus du plus grand signalement légitime, et l’image est analysée chaque semaine |
| 2026-10-17 | Test de mutation des règles d’autorisation | Les politiques d’accès aux signalements, aux documents des signalements et aux dispositifs d’alerte, chaque règle étant délibérément modifiée pour confirmer que la suite de tests détecte le changement | Chaque modification de ces politiques a été détectée. Aucun défaut d’autorisation constaté |
| 2026-10-18 | Revue du code avant l’évaluation indépendante | Champs de téléversement et accès aux fichiers, suppression des métadonnées, blocage jusqu’à l’analyse antivirus, rôles sur les dossiers, administration de la plateforme, journalisation de l’authentification, signalement des erreurs, mots de passe des lanceurs d’alerte | Dix constats. Neuf corrigés le jour même : un champ de téléversement acceptait l’identifiant d’un fichier déjà stocké, si bien qu’un utilisateur pouvait joindre un fichier qu’il n’avait pas téléversé puis l’ouvrir (les liens vers les fichiers expirent désormais aussi au bout d’une heure) ; après la suppression des métadonnées d’un PDF, l’auteur d’origine restait récupérable dans une révision antérieure du fichier ; l’export des données incluait des fichiers qui n’avaient pas passé l’analyse antivirus, et un fichier dont l’analyse n’avait jamais été programmée était servi sans analyse ; un observateur affecté à un dossier pouvait agir dessus ; le panneau d’administration de la plateforme n’exigeait pas de second facteur ; les codes de connexion à usage unique et les assertions SAML parvenaient au service de suivi des erreurs ; les échecs de connexion, les recherches de dossier échouées et les limites de débit atteintes ne laissaient aucune trace ; les lanceurs d’alerte choisissaient eux-mêmes leur mot de passe à six chiffres, si bien qu’un choix courant comme 123456 était accepté (les nouveaux signalements reçoivent un mot de passe à 16 chiffres généré par le système ; les signalements envoyés avant conservent le leur, voir Constats ouverts connus). Une vérification en lecture seule de la production n’a trouvé aucun PDF de signalement stocké ni aucun compte observateur, de sorte qu’aucun de ces deux problèmes n’avait touché un dossier. Le constat restant figure parmi les constats ouverts connus |
Constats ouverts connus #
| Constat | Position |
|---|---|
| Aucun pare-feu applicatif ni CDN devant l’origine applicative | Choix délibéré. L’hébergement direct de l’application et des fichiers se trouve dans l’UE, tandis que la chaîne de messagerie électronique et de télémétrie peut impliquer des traitements en aval hors de l’EEE. La protection anti-DDoS au niveau réseau chez l’hébergeur, associée à la limitation de débit applicative, constitue l’arbitrage actuel. |
| Les photos de profil du personnel sont stockées avec leurs métadonnées d’origine | Délibéré. La suppression des métadonnées protège les lanceurs d’alerte et leurs preuves. Une photo de profil est choisie et téléversée par la personne qu’elle représente. |
| Les signalements envoyés avant le 18 octobre 2026 conservent le mot de passe à 6 chiffres choisi lors de leur envoi, par le lanceur d’alerte ou, pour un signalement enregistré par le personnel, par le gestionnaire du dossier | Accepté. Ces mots de passe fonctionnent toujours et ne sont pas remplacés. La connexion autorise 10 tentatives de mot de passe par référence du dossier par période de 10 minutes, depuis n’importe quelle IP. |
Ce que cela n’établit pas #
- L’opérateur a défini le périmètre, exécuté les tests et rendu compte des résultats. Rien n’a été vérifié de manière indépendante.
- Une campagne sans constat est une preuve portant sur les cas testés, non sur ceux qui ne l’ont pas été.
- La mesure A.5.35 de l’autoévaluation ISO/IEC 27001:2022, la revue indépendante de la sécurité de l’information, reste ouverte pour cette raison. C’est la seule mesure de l’Annexe A de cette autoévaluation enregistrée comme en cours de traitement, et la même limite maintient le chapitre 9.2 (audit interne) à l’état partiel — voir le registre d’audit interne.
Dernière mise à jour: