23 millions de personnes. 22,5 millions d’enregistrements. 11 millions de plus.
Voilà le bilan de ShopServe, Sourcenext et Burger King Japan, trois des fuites que des entreprises japonaises ont révélées ces dernières semaines.
Ce ne sont pas les seules.
Le 9 octobre, des parlementaires japonais se sont réunis pour discuter des fuites de données qui touchent des entreprises dans tout le pays. Masaaki Taira, qui dirige le groupe cybersécurité du Parti libéral-démocrate, a qualifié la situation d’urgence. Il a demandé une réponse de tout le pays, gouvernement et public ensemble.
Le conseil du gouvernement ce jour-là était simple : corrigez vite les vulnérabilités web, vérifiez vos fournisseurs et surveillez qui accède à vos données les plus importantes.
Une semaine plus tard, JPCERT/CC, l’équipe nationale japonaise de réponse aux incidents, a montré comment les attaquants procédaient. Ils ont utilisé l’IA pour chercher des faiblesses connues et attaquer des API. Ils ont même étudié le code d’applications mobiles pour trouver d’autres API à attaquer.
Ce numéro suit cette histoire du début à la fin.
Dans ce numéro
🌡️ Niveau de menace : alerte élevée
⚡ Actualités couvre trois des fuites : Sourcenext, Burger King Japan et Studio.
🔎 Analyse approfondie plonge au cœur de ShopServe, où des boutiques qui avaient quitté la plateforme des années plus tôt ont tout de même été touchées par la fuite.
🎣 Est-ce du phishing ?
🔬 Recherche technique : comment la réinitialisation de mot de passe de Metabase a donné un accès administrateur aux attaquants (CVE-2026-72898)
🛠️ Outil de la semaine : Blutter, que JPCERT a trouvé dans la boîte à outils des attaquants. Utilisez-le pour voir ce que votre propre application laisse filtrer.
👏 Personnalité de la semaine : Loren Kohnfelder, auteur du livre Designing Secure Software
📅 Événement de la semaine : CODE BLUE à Tokyo, les 17 et 18 novembre, où intervient Shusei Tomonaga, CTO de JPCERT/CC.
📚 Livre de la semaine : Designing Secure Software, sur la conception d’applications qui restent sûres même quand les attaquants savent exactement comment elles fonctionnent.
😅 Le mème
❓ Une question avant de partir.
C’est parti.
🌡️ Niveau de menace
⚡ Actualités
Des attaquants ont abusé de l’API des membres de Sourcenext, mettant 22,5 millions d’enregistrements en danger
Sourcenext est une entreprise japonaise de logiciels qui vend des applications et des logiciels pour PC aux particuliers.
Du 9 au 13 octobre, des attaquants ont abusé de l’API que Sourcenext utilise pour consulter les informations des membres. L’entreprise recense 22 519 960 enregistrements potentiellement concernés.
Selon les clients, ces enregistrements peuvent contenir des adresses e-mail, des mots de passe, des noms, des adresses postales, des numéros de téléphone, des dates de naissance et des informations de compte. Les données de carte n’étaient pas stockées dans le système touché.
Pourquoi c’est important : les données exposées peuvent inclure les mots de passe des clients. C’est cela qui doit inquiéter.
La plupart des gens utilisent le même mot de passe à plusieurs endroits. Avec votre e-mail et votre mot de passe Sourcenext, les attaquants peuvent donc tenter de se connecter à votre messagerie, à vos comptes de shopping, voire à votre compte professionnel. Si vous l’avez réutilisé, ils entrent.
C’est pourquoi l’avis de Sourcenext demande aux clients de changer ce mot de passe partout où ils l’ont utilisé.
L’application de Burger King Japan a laissé fuiter environ 11 millions d’enregistrements de membres
Du 2 au 7 octobre, des attaquants se sont introduits dans le système qui gère les adhésions à l’application de Burger King Japan. L’entreprise a confirmé une fuite d’environ 11,18 millions d’enregistrements : noms, coordonnées, dates de naissance et informations d’adhésion.
Aucun numéro de carte n’était conservé dans ce système, et rien n’indique pour l’instant que des mots de passe aient fuité. La façon dont les attaquants sont entrés fait toujours l’objet d’une enquête.
Pourquoi c’est important : aucun numéro de carte n’a fuité, il est donc facile de croire que celle-ci est sans danger. Ce n’est pas le cas.
Avec un nom, un numéro de téléphone et une date de naissance, un escroc peut vous envoyer un message en se faisant passer pour Burger King. Comme il connaît de vrais détails sur vous, le message paraît authentique. Vous touchez le lien, et une fausse page vous demande votre mot de passe ou votre numéro de carte.
C’est pourquoi Burger King invite ses clients à se méfier des e-mails, SMS et appels suspects.
Les données de Studio étaient chiffrées. L’attaquant a aussi atteint les clés.
Une vulnérabilité chez Studio, un créateur de sites web japonais, a permis à un attaquant d’accéder à son environnement cloud. Tous les clients inscrits sont potentiellement concernés.
Ce qui a pu être exposé : les détails des comptes, le contenu des sites, les réponses aux formulaires et les clés d’API que les clients utilisaient pour connecter Studio à d’autres services. Studio n’a pas confirmé que les données ont été téléchargées, mais réagit comme si c’était le cas.
Pourquoi c’est important : Studio est le cas à lire de près, car trois choses qui paraissent habituellement sûres n’ont pas tenu :
Chiffrées. Certaines données étaient chiffrées, mais l’attaquant a aussi atteint les clés pour les déchiffrer.
Supprimées. Les réponses aux formulaires placées dans la corbeille ont peut-être aussi été exposées. Seules celles supprimées définitivement avant le 30 septembre ont été épargnées.
Corrigé. Corriger Studio ne met pas fin à l’affaire. Les clients ont dû remplacer eux-mêmes certaines des clés de leurs autres services.
Un créateur de sites web ne contient pas seulement des sites. Il détient les clés de tout ce à quoi ces sites se connectent.
🔎 Analyse approfondie
La fuite de ShopServe a exposé des clients de boutiques qui avaient déjà quitté la plateforme
En août 2022, King Jim, l’entreprise japonaise de papeterie, a retiré sa boutique en ligne principale de ShopServe.
Quatre ans plus tard, elle présentait ses excuses à ses clients pour une fuite chez ShopServe.
C’était l’une des 7 858 boutiques actuelles et anciennes touchées par cette fuite, qui a concerné environ 23,36 millions de personnes.
King Jim n’utilisait plus ShopServe. Mais les enregistrements des personnes qui y avaient acheté à l’époque étaient toujours là. Quand ShopServe a été compromis, ces enregistrements ont été exposés.
Cette analyse approfondie pose donc une question simple : quand vous quittez une plateforme, que deviennent les données clients que vous y laissez ?
Ce qui s’est passé chez ShopServe
ShopServe est une plateforme de boutiques en ligne gérée par l’entreprise japonaise E Store. Des milliers d’entreprises l’ont utilisée pour vendre en ligne.
Du 21 mai au 1er août 2026, des attaquants ont exploité une faille dans l’une de ses applications pour exécuter leurs propres programmes et faire sortir du système des informations de sa base de données. E Store n’a pas dit de quelle faille il s’agissait.
E Store a publié son rapport final le 16 octobre. Environ 23,36 millions de personnes ont été touchées, réparties sur 7 858 boutiques actuelles et anciennes. Environ 2,1 millions d’entre elles ont vu une partie de leurs données de carte exposée, mais ni les numéros de carte complets ni les codes de sécurité.
Les attaquants n’ont pas seulement obtenu les données des acheteurs. Ils ont aussi obtenu les identifiants que les boutiques utilisent pour gérer leurs boutiques, ainsi que ceux du programme d’affiliation d’E Store.
Et remarquez les mots « actuelles et anciennes ». Certaines de ces boutiques avaient quitté ShopServe depuis longtemps et ont tout de même été touchées par la fuite.
Deux boutiques qui avaient retiré leur boutique principale de ShopServe et ont quand même été compromises
King Jim, la boutique de papeterie, est partie il y a quatre ans.
L’avis de King Jim du 4 septembre a confirmé que des informations sur ses anciens clients avaient été exposées. Sa boutique en ligne actuelle n’a pas été touchée.
Et il ne s’agissait pas seulement de l’ancienne boutique. L’avis couvrait aussi Office Online, une autre boutique de King Jim déjà fermée. Cette boutique n’existait plus, mais les données de ses clients faisaient toujours partie de la fuite.
Puis est venue la partie difficile. King Jim a dit qu’elle ne pouvait pas vérifier si un client donné était concerné, faute des informations nécessaires. Elle a dû renvoyer ses clients vers E Store avec leurs questions.
King Jim a donc présenté ses excuses pour une fuite sur une plateforme qu’elle avait quittée, sans pouvoir répondre à ses propres clients.
Les enregistrements de PFU remontaient à 2008.
PFU, une société du groupe Ricoh qui fabrique des scanners, a retiré sa boutique principale de ShopServe en octobre 2025. Quelques pages de vente distinctes sont restées sur la plateforme jusqu’en septembre 2026.
Les enregistrements en danger remontaient à décembre 2008 : jusqu’à 169 355 commandes.
Ce qui frappe, c’est le temps qu’il a fallu à PFU pour apprendre que ses propres clients étaient concernés :
2 août : PFU est informée de la fuite.
8 septembre : PFU interroge E Store et apprend que d’anciens clients de sa boutique principale pourraient être touchés.
17 septembre : PFU obtient la confirmation que les données de ses anciens clients ont été touchées.
18 septembre : PFU publie ses excuses.
Cela fait plus de six semaines entre l’annonce de la fuite et la certitude que ses propres clients en faisaient partie.
Les boutiques ont quand même dû répondre à leurs clients
La fuite s’est produite chez ShopServe. Mais ce sont King Jim et PFU qui ont écrit à leurs clients, présenté leurs excuses et répondu aux questions.
C’est ainsi que les clients le voient. Ils n’ont pas acheté chez E Store. Ils ont acheté chez King Jim, ou chez PFU. Quand leurs données fuitent, ils regardent le nom qu’ils connaissent.
Quitter la plateforme n’y a rien changé, parce que les anciennes données étaient toujours là. Personne n’a dit pourquoi elles avaient été conservées, ni si quelqu’un avait demandé qu’elles soient supprimées.
Nous n’avons lu que les avis de ces deux boutiques, sur 7 858. Mais toute boutique qui a quitté ShopServe en laissant derrière elle d’anciennes données clients pourrait se trouver dans la même situation.
Que faire quand vous quittez un fournisseur
Demandez la suppression, par écrit. Quand vous quittez une plateforme, demandez au fournisseur de supprimer les données de vos clients et de confirmer que c’est fait.
Sachez ce qu’il détient encore. S’il doit conserver certains enregistrements, découvrez lesquels et pour combien de temps.
Convenez de ce qui se passe en cas de fuite chez lui. Il doit vous prévenir rapidement et vous dire lesquels de vos clients sont concernés, pour que vous n’attendiez pas six semaines de le savoir.
Changer de plateforme est une étape. Faire supprimer les données de vos clients en est une autre, et elle est facile à oublier.
Sources : Rapport final d’E Store · Avis de King Jim · Avis de PFU
🎣 Est-ce du phishing ?
Un e-mail de « ShopServe Customer Support » indique que vos données font partie de la fuite de ShopServe.
Il connaît votre nom, votre ancienne adresse de livraison et les quatre derniers chiffres de votre carte. Pour voir ce qui a été exposé, il vous demande de vous connecter à un portail d’examen de l’incident.
Examinez de près le message, et l’endroit où mène le bouton.
Est-ce du phishing ?
🔬 Recherche technique
Comment la réinitialisation de mot de passe de Metabase a donné un accès administrateur aux attaquants (CVE-2026-72898)
N’importe qui peut utiliser une page de réinitialisation de mot de passe. C’est le principe : si vous avez oublié votre mot de passe, vous ne pouvez pas vous connecter d’abord.
La page ne devrait donc demander que deux choses, le jeton de réinitialisation reçu par e-mail et un nouveau mot de passe, et ignorer tout le reste.
La page de réinitialisation de Metabase n’ignorait pas le reste. Si un attaquant envoyait un champ supplémentaire, Metabase l’insérait directement dans une requête de base de données. Et il le faisait avant même de vérifier que le jeton de réinitialisation était valide.
C’est CVE-2026-72898, une injection SQL exploitable sans authentification. Elle touche Metabase, l’outil open source que de nombreuses entreprises utilisent pour construire des tableaux de bord sur leurs entrepôts de données.
Elle est notée CVSS 10.0. Des attaquants l’ont exploitée avant qu’un correctif n’existe, d’abord contre le service cloud de Metabase lui-même, puis contre des entreprises qui exécutent Metabase sur leurs propres serveurs dans le monde entier.
Elle est liée à ce numéro. JPCERT/CC a publié une alerte dédiée sur cette faille le 14 août. Le 8 octobre, il a cité les attaques contre Metabase parmi les méthodes à l’origine de la récente vague de fuites dans des organisations japonaises.
JPCERT n’a pas nommé les victimes japonaises ni dit combien elles étaient, et rien de public ne relie cette faille à la fuite de ShopServe de notre analyse approfondie. Ce que cela montre, en revanche, c’est comment un seul outil interne, accessible depuis Internet, peut mener les attaquants aux données clients qui se trouvent derrière.
Ce qu’est Metabase, et pourquoi les attaquants le ciblent
Metabase permet aux membres d’une entreprise de construire des tableaux de bord et d’exécuter des requêtes sans écrire de SQL. Pour cela, il se connecte aux vraies bases de données de l’entreprise (PostgreSQL, MySQL, Snowflake, BigQuery, Redshift et d’autres) et stocke les identifiants de ces connexions.
Par conception, c’est donc un système qui :
Détient des identifiants valides pour les bases de données les plus importantes de l’entreprise.
Peut interroger et exporter les données de toutes ces bases.
Est souvent déployé par une équipe data plutôt que par l’équipe sécurité, et reste parfois accessible depuis Internet pour que chacun puisse l’utiliser de n’importe où.
Metabase conserve son propre état (utilisateurs, sessions, clés d’API, paramètres et ces informations de connexion) dans une base de données applicative interne. C’est dans cette base interne que l’injection atterrit.
Le bug : l’endpoint de réinitialisation acceptait des champs supplémentaires
L’endpoint de réinitialisation de Metabase, POST /api/session/reset_password, déclarait les deux champs qu’il attendait :
request-body :- [:map
[:token ms/NonBlankString]
[:password ms/ValidPassword]]Ce schéma vérifie que token et password sont présents et valides. Il ne rejette pas les autres champs.
La bibliothèque de schémas de Metabase, Malli, traite les maps comme ouvertes par défaut : toute clé supplémentaire dans le corps JSON passait donc la validation et était transmise, avec le jeton et le mot de passe, au code de connexion partagé.
Ce code de connexion commençait ainsi (extrait de auth_identity/provider.clj dans la version 0.58.22) :
(merge request (authenticate provider request))
...
(when-let [user-id (:user-id $)]
(t2/select-one [:model/User ...] :id user-id))Il fusionne la requête avec le résultat de l’authentification, puis recherche l’utilisateur par :user-id.
Quand l’authentification réussit, le résultat contient le vrai :user-id et écrase tout ce qui figure dans la requête.
Quand elle échoue, par exemple parce que le jeton de réinitialisation n’est pas valide, le résultat n’a pas de :user-id. Le merge de Clojure n’écrase que les clés présentes dans les deux maps : un user-id fourni par l’attaquant survit donc à la fusion, et le code recherche ensuite un utilisateur avec lui.
C’est le premier problème : la recherche s’exécutait même quand l’authentification avait échoué.
Comment le champ supplémentaire est devenu une injection SQL
À lui seul, un user-id qui survit permettrait à un attaquant de choisir quel enregistrement utilisateur le code récupère. Ce qui en a fait une injection SQL, c’est la façon dont Metabase construit ses requêtes.
Metabase utilise HoneySQL, une bibliothèque qui construit du SQL à partir de structures de données Clojure. Normalement, les valeurs sont envoyées comme paramètres, ce qui garantit des requêtes sûres. Mais HoneySQL prend aussi en charge une forme :raw dont le contenu va directement dans le texte SQL, sans paramétrage. Comme l’explique l’analyse de Wiz, un objet JSON envoyé comme user-id arrive sous forme de map Clojure, et si cette map a une clé raw, HoneySQL la traite comme une directive d’insérer la chaîne telle quelle dans la requête.
Mis bout à bout :
L’attaquant envoie une requête de réinitialisation avec un jeton quelconque, un mot de passe d’apparence valide et un champ user-id supplémentaire contenant un fragment SQL brut.
La validation passe, car le schéma ne vérifie que les champs qu’il déclare.
La vérification du jeton échoue, donc le résultat de l’authentification n’a pas de user-id pour écraser celui de l’attaquant.
La recherche de l’utilisateur construit sa clause WHERE id = ... à partir du fragment de l’attaquant et l’exécute sur la base de données applicative.
La requête échoue avec une erreur 400 « Invalid reset token », mais à ce stade le SQL injecté s’est déjà exécuté sur la base de données applicative.
Nous expliquons ici le bug, nous ne distribuons pas un exploit fonctionnel. Le payload exact dépend de la base de données qui sert Metabase (H2, PostgreSQL, MySQL ou MariaDB), et un code de preuve de concept public est disponible depuis le 10 août.
Ce que l’attaquant obtient : un accès administrateur et toutes les bases de données connectées
L’injection s’exécute sur le stockage interne de Metabase, pas directement sur les données du client. Cela donne tout de même beaucoup à un attaquant, à cause de ce que contient ce stockage interne. L’avis de l’éditeur s’intitule « SQL injection using an unauthenticated endpoint leading to admin access », et Bishop Fox énumère ce qui en découle :
Un accès administrateur complet à Metabase.
La modification des paramètres de l’application et la lecture des secrets accessibles à l’application en cours d’exécution.
L’interrogation et l’export des données de toutes les bases de données auxquelles Metabase est connecté, avec les privilèges de Metabase.
C’est pourquoi le vecteur CVSS indique un périmètre modifié. Le bug est dans Metabase, mais les dégâts atteignent toutes les bases de données qu’il peut interroger.
Des incidents réels le confirment. Metabase a confirmé une exploitation active, la CISA a ajouté la faille à son catalogue Known Exploited Vulnerabilities le 11 août, et des entreprises dont Framework, Tally, n8n et ChecklyHQ ont révélé que des données clients avaient été consultées via leurs instances Metabase.
Les données signalées comprenaient des noms, des adresses e-mail, des numéros de téléphone, des adresses de facturation, des hachages de mots de passe et des jetons d’API.
Comment Metabase a corrigé la vulnérabilité
Le correctif est livré dans 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 et 0.63.5, avec les versions Enterprise 1.x correspondantes. Metabase auto-hébergé sur les séries de versions 58 à 63 antérieures à celles-ci est touché, et Metabase Cloud a été corrigé avant l’avis public.
Dans le code actuel de Metabase pour la réinitialisation et la connexion, le problème est désormais fermé à plusieurs endroits plutôt qu’à un seul :
Le schéma de l’endpoint est fermé. Il s’écrit désormais [:map {:closed true} ...], de sorte qu’une requête contenant des champs non déclarés est rejetée.
Seuls les champs attendus sont transmis. Le handler appelle select-keys pour transmettre :token et :password, et rien d’autre.
Les données de la requête ne peuvent pas fournir les champs d’identité. Avant la fusion, le code de connexion retire de la requête toutes les clés que l’authentification est censée définir, comme :user-id, :user et :success?.
Pas de recherche sans succès. L’utilisateur n’est résolu que si l’authentification a réellement réussi, et seulement si user-id est un entier positif. Tout le reste est journalisé et refusé.
N’importe laquelle de ces mesures aurait arrêté cet exploit. Les avoir toutes les quatre rend moins probable qu’une erreur future dans une couche devienne un autre CVE.
Que vérifier si vous exécutez Metabase
Appliquer le correctif répond à « suis-je encore vulnérable ? ». Il ne répond pas à « ai-je déjà été compromis ? »
Si /api/session/reset_password était accessible depuis Internet sur une version touchée, l’éditeur et JPCERT disent tous deux de considérer l’instance comme possiblement compromise :
Cherchez le schéma d’exploitation. Un POST /api/session/reset_password renvoyant 400, suivi d’un GET /api/user/current renvoyant 200. JPCERT indique que cette séquence suggère fortement une compromission. Wiz ajoute que les requêtes de réinitialisation légitimes ne contiennent que token et password : tout corps avec une clé user-id est donc suspect.
Vérifiez les indicateurs publiés par JPCERT. Requêtes entre début août et début septembre 2026 provenant de 213.163.202[.]171, 221.216.140[.]49 ou 221.216.140[.]129, ou avec les user agents python-requests/2.33.1 ou Metabase-GHSA-vwf4/2.0. JPCERT précise que ces adresses IP peuvent désormais être utilisées légitimement.
Révoquez et renouvelez. Supprimez toutes les lignes de la table core_session pour mettre fin à toutes les sessions, retirez les clés d’API que personne ne reconnaît, passez en revue les comptes administrateur et renouvelez les identifiants de toutes les bases de données connectées.
Examinez le côté données. Vérifiez l’activité et l’historique des requêtes de Metabase ainsi que les journaux de votre entrepôt de données pour repérer des requêtes ou des exports que personne dans l’équipe n’a lancés.
Si vous ne pouvez pas mettre à jour tout de suite, bloquez /api/session/reset_password au niveau du reverse proxy ou du pare-feu.
Leçons pour les développeurs
Validez ce que vous recevez, pas seulement ce que vous attendez. Un schéma qui vérifie les champs obligatoires mais accepte les champs en plus est un filtre percé. Sur les endpoints non authentifiés, rejetez les champs non déclarés, ou ne transmettez que ceux dont vous avez besoin.
Ne laissez pas les données de la requête partager un espace de noms avec des données de confiance. Fusionner une entrée utilisateur dans une map qui contient aussi le résultat de l’authentification fait qu’une clé manquante d’un côté devient une entrée de l’attaquant de l’autre. Gardez-les séparées, ou retirez d’abord les clés de confiance de l’entrée.
Les chemins d’échec demandent autant de soin que les chemins de succès. Cette recherche s’exécutait après l’échec de l’authentification. Le code qui s’exécute sur le chemin d’erreur reste accessible à quiconque peut déclencher l’erreur, et sur un endpoint de réinitialisation, c’est tout le monde.
Les générateurs de requêtes exigent encore que vous sachiez où est la porte de sortie. HoneySQL paramètre les valeurs par défaut, mais pas sa forme :raw. Si des données non fiables peuvent atteindre un générateur de requêtes sous forme de structure plutôt que de valeur scalaire, vérifiez si cette structure peut exprimer du SQL brut.
Traitez les outils internes comme exposés à Internet quand ils le sont. L’alerte d’octobre de JPCERT cite en particulier les outils de BI et les systèmes des employés : vérifiez-les avec les mêmes mesures que les applications publiques. Un outil de tableaux de bord qui stocke des identifiants d’entrepôt de données est l’un des systèmes les plus précieux qu’un attaquant puisse atteindre.
🛠️ Outil de la semaine : Blutter
Sur un serveur qu’il a examiné, JPCERT/CC a trouvé des fichiers d’applications Android à côté de fichiers liés à deux outils de rétro-ingénierie : le décompilateur JADX et Blutter.
Les attaquants faisaient de la rétro-ingénierie d’applications pour trouver les API qui se cachent derrière, puis testaient ces API à la recherche de faiblesses.
Blutter est celui conçu pour les applications Flutter.
Ce que fait Blutter
Un décompilateur comme JADX ne va pas loin avec une application Flutter, car le code Dart est compilé en code machine natif dans libapp.so. Blutter est conçu pour faire de la rétro-ingénierie de ce fichier. Il vous donne :
Le code de l’application en assembleur, avec les noms de fonctions retrouvés.
Un dump des objets Dart de l’application, où apparaissent les adresses de serveurs et les clés codées en dur.
Un modèle de script Frida pour faire du hooking de l’application à l’exécution.
Comment utiliser Blutter sur votre propre application
Lancez-le sur votre propre application, ou sur une application que vous êtes autorisé à tester. Parcourez les objets extraits à la recherche d’adresses de serveurs et de clés codées en dur, et vérifiez à quoi chaque clé donne accès.
Limites
Android ARM64 uniquement, et versions récentes de Dart. La prise en charge d’iOS n’est pas terminée, et les applications obfusquées ne sont pas entièrement prises en charge.
Ce n’est pas un décompilateur complet. Vous obtenez de l’assembleur et des objets, pas du code source.
L’installation demande des outils de build, et il peut falloir d’abord compiler le runtime Dart correspondant.
À retenir
Avec des outils comme celui-ci, toute personne qui télécharge votre application peut déduire comment elle communique avec votre serveur. Garder l’API à l’intérieur de l’application ne la protège pas.
Ce qui la protège, c’est le serveur qui vérifie, à chaque requête, qui demande et ce qu’il a le droit de voir.
👏 Personnalité de la semaine : Loren Kohnfelder
En 1978, Loren Kohnfelder a rédigé son mémoire de licence au MIT, Towards a Practical Public-key Cryptosystem. Il y introduisait le certificat numérique : un enregistrement signé qui lie une clé publique à un nom. Les certificats qui sous-tendent HTTPS aujourd’hui s’appuient sur cette idée.
Chez Microsoft, avec Praerit Garg, il a créé STRIDE, l’une des méthodes les plus utilisées pour réfléchir aux menaces pesant sur un système. Il a aussi dirigé les travaux de sécurité de la plateforme .NET. Chez Google, il a travaillé dans l’équipe sécurité, aidé à fonder l’équipe confidentialité et passé en revue la conception de sécurité de grands systèmes.
Aujourd’hui retraité, il a mis cette expérience dans le Livre de la semaine de ce numéro.
Pour plus de quarante ans de travail consacrés à rendre les systèmes sûrs dès leur conception, Loren Kohnfelder est notre Personnalité de la semaine.
📅 Événement de la semaine
CODE BLUE 2026
CODE BLUE est une conférence internationale de sécurité à Tokyo. Des chercheurs du Japon, du reste de l’Asie, d’Europe et des États-Unis y présentent leurs derniers travaux, avec des ateliers, des concours et une session pour les intervenants de moins de 25 ans.
Après un numéro sur la vague de fuites au Japon, c’est la suite naturelle. La plupart des conférences bénéficient d’une interprétation japonais-anglais : inutile donc de parler japonais pour suivre.
Une conférence correspond particulièrement bien à ce numéro. Shusei Tomonaga, CTO de JPCERT/CC, et Yuki Yano, de son groupe de réponse aux incidents, présentent Quality Assurance for Incident Response in the Age of AI.
Après une fuite, quelqu’un rédige un rapport d’enquête. Mais comment savoir que ce rapport étaye réellement ses conclusions ?
Dans leur présentation, ils décrivent comment JPCERT/CC a travaillé avec 13 prestataires japonais de réponse aux incidents, CSIRT et équipes SOC pour rédiger deux listes de contrôle et un exemple de rapport, puis a construit un agent LLM qui évalue les rapports à l’aune de ces listes.
📍 Bellesalle Takadanobaba, Tokyo, Japon 📅 17 et 18 novembre 2026
📚 Livre de la semaine
Designing Secure Software
Ce numéro revient sans cesse sur un fait : les attaquants finiront par comprendre comment votre système fonctionne. JPCERT a trouvé des attaquants en train de lire des applications mobiles pour cartographier les API qui se cachent derrière.
Designing Secure Software: A Guide for Developers de Loren Kohnfelder, notre Personnalité de la semaine, part de cette hypothèse. Le livre porte sur l’intégration de la sécurité dans la conception d’un système, et non sur son ajout à la fin.
L’un de ses patterns est le Transparent Design : un système doit rester sûr même quand les attaquants savent exactement comment il fonctionne. Cela ne veut pas dire publier les mots de passe ou les clés. Ceux-ci restent secrets. Cela veut dire que la conception elle-même ne doit pas dépendre du fait d’être cachée.
😅 Le mème
Si l’un de vos anciens fournisseurs était compromis demain, combien de temps vous faudrait-il pour savoir si vos clients ont été touchés ?
The Breach Brief,
L’équipe Ostorlab