Broulala — sécurité et qualité

corrigé A1 — La connexion administrateur n'était pas limitée en débit

POST /admin/v1/session accepte un nombre illimité de tentatives d'adresse et de mot de passe. La limitation de débit existe et fonctionne bien, mais elle est appliquée uniquement sur /v1/* et indexée par clé d'API — c'est-à-dire sur la seule porte qui exige déjà un secret pour être atteinte. La porte qui n'en exige pas est la seule des deux à ne rien avoir devant elle.

Deux dommages distincts, et le second est le moins évident :

1. Force brute sur les mots de passe. Ce que la porte ouvre n'est pas mince : le contenu des organisations dont le compte est membre (§7), l'émission et la révocation de clés d'API, la suspension d'une organisation cliente, et — depuis l'écran d'exploitation — la location d'une carte graphique facturée à la minute.
2. Épuisement de ressources, non authentifié. Chaque tentative déclenche une vérification Argon2id qui alloue 19 Mio et coûte 26 ms de processeur (mesuré). Un attaquant n'a besoin d'aucun identifiant valide pour en déclencher autant qu'il veut, sur une VM de 10 Go qui héberge aussi Notula — et qui est déjà tombée deux fois le 20/09 sous pression mémoire. La défense contre le vol de mot de passe est ici, telle quelle, un levier de déni de service.

Ce qui atténue, et qu'il ne faut pas confondre avec une protection : les comptes sont peu nombreux et leurs adresses ne sont pas publiques, il n'y a pas de création de compte en libre-service, et un reverse-proxy se trouve en amont. Mais aucune de ces trois choses n'est un contrôle que le dépôt possède, et la troisième est une hypothèse que je n'ai pas pu vérifier (voir Q1).

Ce que je recommande, et dans cet ordre. Une fenêtre glissante par adresse IP et par adresse courriel — les deux, parce que l'une seule se contourne par distribution et l'autre seule par rotation d'adresse. Le service src/services/rateLimit.ts existe déjà et prend une clé arbitraire : c'est une quinzaine de lignes de route, pas une construction. Un délai croissant après trois échecs sur la même adresse coûte encore moins et suffit à rendre la force brute inutile.

Attention à ne pas casser deux choses en le faisant. Le refus doit rester 401 INVALID_CREDENTIALS — un 429 distinct sur une adresse existante recréerait l'oracle d'énumération du constat A2. Et la limitation doit compter avant l'appel à Argon2, sinon elle ne protège pas du second dommage.

corrigé A2 — La connexion révélait par le temps si une adresse existe

Dans src/routes/admin/session.ts, le court-circuit de l'opérateur || fait que passwordMatches n'est pas appelé du tout quand l'adresse est inconnue. Et même appelé, il rend false immédiatement si le condensat stocké est nul, sans exécuter Argon2.

Conséquence : une adresse inconnue répond en ≈ 1 ms, une adresse connue avec un mauvais mot de passe en ≈ 27 ms. L'écart est d'un ordre de grandeur et parfaitement mesurable à distance. Un attaquant énumère ainsi les comptes de la console, ce qui rend le constat A1 sensiblement plus rentable.

L'ironie mérite d'être relevée, parce qu'elle indique où est l'angle mort. Les trois lignes qui suivent immédiatement ont été écrites pour éviter exactement ce défaut : « Vérifié après le mot de passe, pas avant : refuser plus tôt répondrait plus vite pour un compte suspendu que pour un mot de passe faux, et une différence de temps est un oracle comme un autre. » Le raisonnement est juste ; il n'a pas été appliqué un cran plus haut, là où le compte n'existe pas du tout.

Correction : vérifier un condensat factice lorsque l'adresse est inconnue, pour que les deux chemins paient le même Argon2. Une constante de condensat leurre engendrée au démarrage suffit ; c'est trois lignes.

corrigé A3 — Aucune limite de mémoire sur les conteneurs

Ni compose.yaml ni l'override ne déclarent mem_limit, cpus ou une section deploy.resources. Un seul conteneur peut donc consommer toute la VM.

Ce n'est pas théorique : c'est arrivé deux fois le 20/09/2026. La machine est tombée sous pression mémoire, et la mesure prise en réponse a été de retirer le moteur dégradé du démarrage automatique — ce qui a coûté un vrai filet (il n'y a plus qu'un seul chemin de transcription) pour un problème que trois lignes de limites auraient borné. La VM porte dix gigaoctets et deux applications complètes.

Correction : une limite par service, dimensionnée sur l'observation plutôt que devinée, et un restart: unless-stopped déjà présent qui fera le reste. C'est aussi ce qui permettrait de relever le moteur dégradé sans reprendre le risque, et donc de rendre à la plateforme le chemin lent qu'elle a perdu.

corrigé A4 — Une violation de contrainte d'unicité devenait un 500

Aucun endroit du code ne rattrape P2002. Toute course sur un index unique remonte donc jusqu'au gestionnaire générique et devient INTERNAL_ERROR.

Le cas le plus gênant est l'idempotence elle-même, et c'est ce qui fait la sévérité. src/services/idempotency.ts lit puis écrit (findFirst suivi de create) : deux requêtes simultanées portant la même Idempotency-Key passent toutes deux la lecture, et la seconde échoue en 500. Or la simultanéité est précisément le cas pour lequel l'idempotence existe — un client qui ré-émet sur délai d'attente réseau. Le contrat promet « la même clé rend le même résultat » ; sous concurrence réelle, elle rend une erreur serveur.

Les mêmes courses existent, moins gravement, sur Organisation ↔ email (EMAIL_ALREADY_EXISTS est vérifié avant, donc rattrapable) et sur l'index (jobId, status) de WebhookDelivery.

Correction : traiter P2002 comme un fait normal plutôt que comme un accident. Sur l'idempotence, la violation est la réponse — elle signifie « quelqu'un d'autre a réservé cette clé », donc on relit et on rejoue. Un utilitaire partagé dans src/db/ qui traduit P2002 en un refus nommé vaut mieux qu'un try par site d'appel.

corrigé A5 — Le journal des lectures ne se lisait nulle part et ne s'élaguait jamais

Le §7 des instructions du dépôt promet : « Une lecture de contenu est journalisée — qui, quel appel, quand. C'est ce qui reste quand la confiance ne suffit plus. » La table ContentRead existe et est bien écrite à chaque lecture (src/routes/admin/jobs.ts:279). Deux choses manquent autour.

Personne ne peut la lire. Aucune route d'administration, aucun écran de console ne la consulte. « Ce qui reste » n'est donc atteignable qu'en ouvrant un psql sur la base de production. Le jour où un client demande « qui a lu la transcription de mon appel », la réponse existe et n'est pas servable — et c'est exactement la promesse que le §7 dit pouvoir faire « sans réserve » à un tiers.

Et elle grossit sans fin. Toutes les autres tables ont une règle de rétention — résultats à 30 jours, DailyUsage à 13 mois, MachineWindow à 7 jours, médias à 48 h après un échec. ContentRead n'apparaît nulle part dans src/services/maintenance.ts. Elle accumule indéfiniment des couples utilisateur nommé ↔ appel client ↔ horodatage, c'est-à-dire de la donnée personnelle sur les administrateurs, sans durée. Une plateforme qui borne tout le reste à la journée ou au mois garde ceci pour toujours.

corrigé A6 — Les deux services qui dépensent de l'argent n'avaient aucun test

src/services/raiseMachine.ts et src/services/stopMachine.ts portent quatre refus qui protègent chacun quelque chose de concret :

Aucun test du dépôt ne nomme l'un de ces quatre. Les boîtes de contrat qui couvrent ces routes n'affirment que l'autorisation — « seul un super admin peut demander », « seul un super admin peut arrêter ». Le comportement, lui, n'est affirmé nulle part : ni la retenue, ni le refus sur travail en cours, ni l'idempotence par l'état.

Pourquoi ça pèse plus qu'un trou de couverture ordinaire : ces deux fonctions ont un effet irréversible et facturé, elles sont récentes, et le port Compute existe précisément pour qu'elles soient testables sans appeler un fournisseur. Le coût du test est donc faible et le coût de l'absence est en euros.

corrigé A16 — request.ip était écrit par l'appelant

src/app.ts posait trustProxy: env.NODE_ENV === 'production', c'est-à-dire true — « fais confiance à tous les intermédiaires ». Fastify résout alors request.ip depuis X-Forwarded-For en prenant l'entrée la plus à gauche, qui est celle que le client a écrite. L'adresse que la plateforme croit être la source est donc choisie par la source.

Deux conséquences, et la première n'est pas celle qu'on attend :

1. Tout compteur indexé sur l'IP est contournable en changeant l'en-tête à chaque requête — et son espace de clés devient illimité par la même occasion, ce qui en fait un levier de consommation mémoire plutôt qu'une protection. C'est la raison pour laquelle le compteur de connexions de A1 a un troisième plafond, global : c'est le seul dont la clé n'est pas choisie par celui qu'il compte.
2. Toute adresse journalisée est déclarative. Le remoteAddress des lignes de journal ne dit pas d'où venait un appel, il dit ce que l'appel prétendait. Personne n'en dépend aujourd'hui, et c'est exactement pour ça qu'il faut l'écrire avant que quelqu'un s'y fie.

Ce qui atténue : l'API n'écoute que sur la boucle locale, derrière un reverse-proxy, donc l'en-tête arrive par un chemin contrôlé — mais rien n'empêche un client d'en envoyer un que le proxy complétera au lieu de le remplacer.

Correction : remplacer true par le nombre de sauts réels, ou par le réseau du proxy. La difficulté est qu'il faut connaître ce nombre, et se tromper coûte cher dans les deux sens — trop bas, l'adresse devient celle du proxy pour tout le monde ; trop haut, on revient ici. À faire en regardant la chaîne réelle, ce que cet audit n'a pas fait (voir Q1). Le plafond global de A1 rend ce travail non urgent, ce qui est précisément pourquoi il a été écrit comme ça.

corrigé A17 — La machine n'avait aucun espace d'échange

free -m sur l'hôte, le 21/09/2026 : Swap: 0 0 0. La VM porte dix gigaoctets, deux applications complètes, et rien derrière elle.

C'est la cause profonde de A3, et elle survit à sa correction. Sans espace d'échange, un pic de mémoire ne ralentit pas la machine : le noyau tue un processus, et rien ne garantit qu'il choisisse le fautif. Les plafonds posés le 21/09 bornent ce qu'un conteneur peut prendre — ils ne donnent aucune marge à ce qui vit hors conteneur, et c'est un docker build, qui n'est borné par aucun d'eux, qui a fait tomber la machine le 20/09.

Et c'est ce qui rend le moteur dégradé inabordable aujourd'hui. Avec 3,85 Gio résidents et aucune marge, le relever revient à parier qu'aucune construction d'image n'aura lieu pendant qu'il tourne.

Correction — quatre commandes, à passer sur l'hôte. Elles demandent sudo, donc elles reviennent à l'exploitant :

sudo fallocate -l 4G /swapfile && sudo chmod 600 /swapfile
sudo mkswap /swapfile && sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab
echo 'vm.swappiness=10' | sudo tee /etc/sysctl.d/99-swappiness.conf && sudo sysctl --system

La troisième ligne est celle qu'on oublie : sans elle, l'espace d'échange disparaît au prochain redémarrage et le problème revient sans prévenir. La quatrième dit au noyau de ne s'en servir qu'en dernier ressort — un swappiness par défaut ferait paginer Postgres alors qu'il y a de la mémoire libre, ce qui échange une panne rare contre une lenteur permanente.

Ce que ça ne fait pas : rendre quatre gigaoctets gratuits. Un espace d'échange transforme un arrêt brutal en ralentissement, ce qui est un bien meilleur échec — pas en capacité supplémentaire. Vérifier après coup avec free -m : la ligne Swap doit annoncer 4096.

corrigé A7 — Les instructions affirment une protection CSRF qui n'existe pas

Le §8 de CLAUDE.md écrivait « CSRF sur toutes les mutations d'administration » dans une liste introduite par « Chaque point a un test ». Il n'y a ni implémentation ni test, et le commentaire de src/routes/admin/index.ts:118 le dit à demi-mot : la protection « arrive avec le front qui en a besoin ».

Et elle n'en a pas besoin — c'est le point important. La console s'authentifie par Authorization: Bearer depuis sessionStorage, sans aucun cookie et sans credentials: 'include' : un navigateur n'envoie rien de lui-même, donc CSRF est structurellement impossible, exactement comme sur l'API d'intégration que le §8 déclare exempte « par construction ».

Le défaut n'est donc pas une faille, c'est une fausse assurance dans un document de sécurité — le genre de phrase sur laquelle on s'appuie pour ne pas regarder. Correction : écrire que les deux portes sont exemptes par construction, et dire ce qui la rouvrirait (passer le jeton en cookie).

corrigé A8 — Les commandes privilégiées en ligne de commande n'ont aucun test

adminPromote (qui accorde ou retire le drapeau de super-administrateur), orgCreate, userCreate, catalogueSeed et templateTry ne sont couverts par aucun test. Ce sont les seules voies par lesquelles un droit global s'octroie, et elles s'exécutent sur la production.

Le risque n'est pas qu'elles soient contournables — elles exigent un accès au serveur — mais qu'une régression silencieuse y passe : une inversion de drapeau, une promotion qui ne révoque pas. Correction : un test par commande sur la base de test, du même type que ceux qui couvrent déjà pod.ts.

corrigé A10 — Aucune limite d'erreur React : une faute de rendu vide la console

Aucun ErrorBoundary dans web/src/. Une exception dans un rendu démonte l'arbre entier et laisse une page blanche, sans message ni moyen de revenir. Pour une console d'exploitation, « écran blanc » est le pire diagnostic possible : il ne dit pas si la plateforme est tombée ou si c'est l'affichage.

Correction : une limite d'erreur à la racine qui affiche l'identifiant de requête et un bouton de rechargement. Une vingtaine de lignes.

documenté A11 — Le quota est un disjoncteur, pas une barrière

Le plafond est lu à l'admission et la consommation écrite à la complétion. Plusieurs jobs soumis dans la même fenêtre passent donc tous le contrôle avant qu'aucun ne compte : le dépassement possible vaut nombre de jobs simultanés × coût unitaire. La limitation par clé le borne, et c'est la nature d'un disjoncteur. À documenter plutôt qu'à corriger — une barrière stricte demanderait une réservation, donc une transaction sur le chemin chaud.

corrigé A12 — Le journal n'a pas de redact, et sérialise les erreurs sans borne

log.error({ err: error }, 'unhandled error') sérialise l'erreur entière. Le test du corpus marqué couvre le chemin des moteurs fictifs ; une erreur inattendue d'une autre origine — une contrainte Prisma, un analyseur JSON — pourrait porter une valeur d'entrée dans son message. Le risque est résiduel et la discipline actuelle est bonne ; une liste redact explicite sur authorization et err.meta coûterait deux lignes et fermerait la classe.

corrigé A13 — HSTS sans includeSubDomains ni preload

L'en-tête servi était max-age=31536000 seul. Correct et conditionné au HTTPS, donc jamais trompeur en clair — mais un sous-domaine reste attaquable en rétrogradation. À décider selon ce qui vit sous broulala.fr.

documenté A14 — La limitation de débit est en mémoire de processus

Les fenêtres vivent dans une Map : elles repartent à zéro à chaque déploiement, et une seconde instance d'API doublerait mécaniquement les plafonds. Sans conséquence aujourd'hui — il y a une instance, et le dépôt refuse Redis à raison — mais c'est une hypothèse à écrire avant qu'elle ne se périme.

corrigé A15 — Durcissement de conteneur incomplet

L'image tourne bien en USER node et les ports sont sur la boucle locale, ce qui est l'essentiel. Manquent security_opt: [no-new-privileges:true], cap_drop: [ALL] et read_only: true — trois lignes par service, sans effet fonctionnel attendu hors du volume d'envois qui doit rester inscriptible.

corrigé A18 — Un correctif, deux images, une seule reconstruite

Le moteur dégradé et la machine louée partagent pod/sitecustomize.py — le fichier qui rend l'image utilisable du tout, et qui porte depuis le 20/09 le correctif du vocabulaire. Ce sont deux images distinctes. Corriger la source et reconstruire l'une ne reconstruit pas l'autre.

Mesuré le 21/09/2026, et le client l'a payé. L'image du pod a été republiée en :8 le 20 ; celle du moteur dégradé est restée sur une construction de quatre jours. Deux cours portant un transcription.vocabulary sont partis sur le chemin dégradé et ont échoué en PROCESSING_FAILED — pour exactement le défaut qu'on croyait corrigé la veille.

Le contrôle qui aurait tranché en une seconde, et qui n'a été écrit qu'après :

docker run --rm --entrypoint sh broulala-whisper:latest \
  -c "grep -c initial_prompt /opt/broulala/sitecustomize.py"
# 0 avant, 13 après

Ce qui reste ouvert n'est pas l'incident mais la classe. L'image est reconstruite et vérifiée ; rien n'empêche la prochaine modification du correctif partagé de repartir sur la même erreur. npm run test:pod-image prend une image en argument et sait donc vérifier les deux — ce qui manque est que quelqu'un sache qu'il faut le faire deux fois. C'est écrit dans le compose à côté du service, et ce n'est pas un contrôle.

documenté A19 — Recréer le tunnel coupe le worker et le superviseur

worker et supervisor déclarent network_mode: 'service:tunnel' : ils partagent l'espace réseau du conteneur du tunnel, ce qui est exactement ce qu'on veut — le trafic vers les moteurs loués passe par ses redirections locales.

Mais recréer le tunnel seul leur laisse une référence morte. Les deux continuent de tourner, se déclarent en bonne santé, et échouent sur chaque sortie réseau. Mesuré le 21/09/2026 : supervisor: pass failed — fetch failed toutes les vingt secondes, à partir de vingt secondes après un docker compose up -d tunnel. Pendant ce temps plus aucune machine n'est levée ni couchée, et rien ne le dit.

Ce qui le rend vicieux : la commande qui casse est celle qu'on tape pour réparer le tunnel, et le symptôme apparaît ailleurs, sur deux services qu'on n'a pas touchés. Un docker compose up -d complet les recrée et ne pose pas le problème ; c'est le déploiement ciblé qui l'introduit.

Correction : recréer les trois ensemble — docker compose up -d --force-recreate tunnel worker supervisor — et l'écrire là où on lit comment déployer. Un depends_on n'y suffirait pas : il ordonne un démarrage, il ne force pas une recréation.