Draw A Fish ! Postmortem

• Le 3 août 2025, un incident de sécurité majeur a touché le site DrawAFish! pendant près de 6 heures
• La fuite du mot de passe administrateur, une API sans authentification et une faille de validation JWT ont exposé plusieurs vulnérabilités clés à l’attaque
• En conséquence, tous les noms d’utilisateur ont été modifiés en expressions offensantes, des dessins inappropriés ont été approuvés et des dessins sûrs existants ont été supprimés
• L’incident a été résolu via une restauration manuelle, la correction de la logique d’authentification et la vérification des sauvegardes
• La leçon principale est que la rapidité de développement (“vibe-coding”) associée au manque de tests et de revue de code peut avoir de graves conséquences de sécurité

---

Présentation de DrawAFish.com et résumé de l’incident du 3 août 2025

• DrawAFish.com est un site où les utilisateurs dessinent leurs propres poissons et les font nager dans un aquarium avec d’autres utilisateurs
• Le 1er août 2025, le site a reçu une forte attention en atteignant la première place de Hacker News. Le développeur a adopté une approche de « vibe-coding » pour implémenter rapidement les fonctionnalités avec des outils comme Copilot

• Pourtant, au petit matin du 3 août 2025, une violation de sécurité grave s’est produite
• Pendant près de 6 heures, les noms d’utilisateur ont été remplacés par des termes obscènes et des dessins inappropriés ont été approuvés, provoquant un désordre généralisé
• L’administrateur a finalement exécuté une restauration manuelle

Analyse détaillée des vulnérabilités

1. Mot de passe administrateur compromis (6 caractères)

• Le développeur a utilisé son propre identifiant d’enfance et un mot de passe à 6 caractères pour le compte administrateur
• Ce mot de passe avait déjà été divulgué en ligne via des fuites de données de sites comme Neopets
• Le développeur a ensuite activé Google Auth, mais n’a pas supprimé l’ancien mot de passe, laissant une vulnérabilité exploitable pour les attaquants
• L’attaquant a utilisé ces informations compromises pour réussir l’authentification administrateur, puis a accompli des actions malveillantes comme l’approbation de dessins offensants et la suppression de dessins normaux

2. API de modification de nom d’utilisateur sans authentification

• Le backend profil a été conçu pour aller vite, avec une API de changement de nom d’utilisateur implémentée sans vérification d’authentification
• En pratique, n’importe qui pouvait modifier le nom d’utilisateur de manière arbitraire

3. Vérification JWT insuffisante

• Dans l’authentification basée sur un token JWT, les opérations d’administration étaient possibles sans faire correspondre le token avec le couple userId/email
• Ainsi, un attaquant ayant un token émis via des informations d’authentification administrateur pouvait l’utiliser avec des privilèges admin pour n’importe quelle requête
• Fait intéressant, un utilisateur de Hacker News a utilisé cette vulnérabilité pour supprimer le contenu inapproprié avant l’attaquant, aidant ainsi à la réponse d’urgence

Processus de récupération

• Vers 7 h 45, le développeur a constaté l’ampleur du problème et a commencé la réponse immédiatement depuis son ordinateur de bureau
• Les sauvegardes Firebase n’étaient pas configurées, donc il n’a pas pu s’appuyer dessus, et il a rapidement corrigé le code pour appliquer l’authentification de façon stricte
• Il a retracé tous les logs de modération et créé un script pour annuler les actions malveillantes (également écrit en mode vibe-coding)
• En situation d’urgence, il a également bloqué un compte tiers avec des privilèges administrateur (un utilisateur de Hacker News), puis l’a contacté pour obtenir un retour sur le refactoring de sécurité de la base de code et appliquer des correctifs supplémentaires

Culture de développement et enseignements

• Le développeur a constaté que le “vibe-coding”, c’est-à-dire le prototypage rapide avec peu de vérifications, peut offrir du fun et une forte productivité, mais peut aussi mener à de graves vulnérabilités de sécurité
• Les LLM (Copilot) sont extrêmement utiles pour produire du code rapidement, mais la qualité et la sécurité du code restent la responsabilité du développeur
• La suppression des contrôles essentiels comme les tests, la logique d’authentification et la revue de code a montré qu’un projet de petite taille peut devenir extrêmement vulnérable à des attaques externes

Conclusion et enseignements

• Le cas DrawAFish.com illustre l’importance des mesures de sécurité de base souvent négligées dans l’exploitation de services réels
• Même en s’appuyant sur des outils open source et des outils de développement rapides, il faut toujours vérifier des points fondamentaux comme tests, authentification, revue de code et gestion des mots de passe
• Une visibilité soudaine à grande échelle (par ex. un classement élevé sur Hacker News) peut faire exploser rapidement la surface d’attaque et le risque
• La publication transparente du postmortem a permis de transmettre des enseignements de sécurité réalistes aux startups et aux développeurs indépendants confrontés à des cas similaires

[crawler]

Le "S" de vibe-coded est l'abréviation de Security.

[wkbae]

De manière intéressante, un utilisateur de Hacker News a utilisé cette faille de sécurité pour supprimer des données inappropriées avant l’intrus, contribuant ainsi à la réponse d’urgence.

[GN⁺]

Commentaires Hacker News

• Moi aussi, j'adore travailler vite, c'est vraiment agréable d'appuyer sur push directement sans attendre une revue de code. Mais ce post-mortem m'a fait comprendre pourquoi mes side projects sont souvent interrompus : je m'arrête toujours quand je dois enfin faire le vrai boulot, la partie un peu ennuyeuse.
• Je me demande si c'était Firebase, avec le free tier utilisé en continu, ou si quelqu'un les a attaqués volontairement pour qu'ils se réveillent avec une facture à cinq chiffres.
• Je suis l'une des personnes « chanceuses » à avoir vécu l'affaire Sloppy Fish. Comme je travaille en sécurité, j'ai trouvé la situation tellement évidente que j'en ai presque ri, et je savais qu'une personne ayant du temps pour aider allait bien apparaître sur HN. J'ai aimé voir un post-mortem aussi détaillé publié pour un projet vibe-coded. En ce moment, dans mon travail d'IR (Incident Response), je vois beaucoup de code vibe-coded en production, donc c'est impressionnant de voir un niveau aussi propre, même sur un si petit projet.
  • Les gens disent souvent que le problème vient du « vibe coding », mais au moins deux points — « laisser un compte admin de test » et « valider le token sans effectuer de vérification croisée » — sont des erreurs qui surviennent couramment même sans IA ni vibe coding.
  • Une capture d'écran du poisson en forme de swastika (le « swastik-fish ») aurait été bienvenue ; malheureusement je ne l'ai pas vu en vrai.
• Ce post-mortem est d'autant plus intéressant parce qu'il s'agit d'une app vibe-coded ; je me demande s'il s'est inspiré de l'exposition de fabrication de poissons au Lego House. Je suis allé récemment : voir mon poisson nager avec d'autres poissons était incroyablement addictif. Vidéo YouTube Build-a-Fish de Lego House
  • Je ne connaissais pas cette exposition ; à l'aquarium de St Louis, des poissons peints ont l'air de vraiment nager, et l'idée semble datée d'environ 2016 avec Google Quick, Draw.
• C'est incroyable qu'on ait utilisé une vulnérabilité pour tenter d'empêcher une attaque réelle.
  • On a déjà vu ça auparavant : certains worms/exploits avaient eux-mêmes corrigé la vulnérabilité pour la bloquer.
  • J'ai lu un article où le FBI avait fait quelque chose de similaire contre l'exploit EternalBlue il y a quelques années (le nom exact de l'exploit n'est peut-être pas ça).
  • Les gens sont vraiment extraordinaires.
• Le « S » de vibe-coded signifie Security.
  • Le « S » pourrait aussi bien vouloir dire Serpent... ou Dragon.
• C'est une vraie marque de professionnalisme que d'inventer une idée totalement neuve, de la construire soi-même, d'apprendre énormément, puis d'assumer avec humilité ses échecs. Si on ne perd pas 100 000 $, si le réseau ne s'écroule pas et si on ne perd pas son emploi, on peut rire de tout ça un an plus tard.
• Il y avait en ce moment sur le site un poisson en forme de swastika ; quelqu'un l'avait glissé dans une forme de poisson pour contourner le filtre : lien de l'image problématique. Il est actuellement supprimé.
  • Il y avait aussi un poisson avec le mot « Balls » dessus : on peut le voir ici. À ce stade, je pense qu'il n'y a pas grand-chose de problématique.
  • Ce poisson donne vraiment l'impression d'avoir la touche du Bouddha.
• Actuellement, il est possible de voter pour n'importe quel poisson sans authentification (jusqu'à 20 fois par minute et par IP) via POST sur l'URL suivante : lien vers l'API de vote {"fishId":"xxxx","vote":"up"}
  • C'était volontairement conçu ainsi : certains poissons peuvent être aimés un peu, d'autres beaucoup, donc la possibilité de voter positif/négatif à l'envi était voulue.
• J'ai vraiment apprécié le post-mortem laissé sur un site vibe-coded. Beaucoup de gens traitent la technique trop sérieusement, donc cette approche légère et amusante fait du bien ; vu de l'intérieur d'un petit side project, c'est vraiment intéressant et porteur de sens.