🛡️ « Holding the Core » : l'ingénierie de la sécurité vue par Darkwaar40 — Breach

le 25 octobre 2026

Darkwaar40 — Breach commence avec trois portails ouverts.

Situés à la périphérie d’un donjon circulaire, ils font sans cesse apparaître des entités hostiles : des logiciels malveillants courants, des exploits plus rapides et des failles « zero-day » plus tenaces. Au centre se trouve un noyau doté de 100 points d’intégrité. Le joueur se déplace ; un scanner automatique tire sur la menace la plus proche à portée ; fermer un portail voisin interrompt son tir pendant quelques secondes. Survivez pendant 100 secondes et le système tient bon. Si l’intégrité atteint zéro, c’est l’échec.

Il s’agit d’un jeu de survie compact, et non d’un simulateur de sécurité. Un projectile ne peut pas modéliser la détection au niveau des terminaux, un monstre ne peut pas refléter l’ambiguïté d’un véritable rapport de vulnérabilité, et une barre de santé ne dit rien sur les données confidentielles qui quittent un système sans être remarquées.

Cette simplification reste néanmoins utile, car Breach saisit parfaitement une idée centrale :

La sécurité n’est pas un mur que l’on construit une fois pour toutes. C’est un processus continu consistant à réduire l’exposition, à détecter les activités hostiles, à réagir sous pression et à maintenir le système opérationnel.

Ce processus est visible à chaque partie. Tuer des ennemis sans fermer les portails ne fait que traiter les symptômes tandis que la source reste active. Sceller tous les portails sans surveiller le Noyau revient à ignorer les menaces déjà présentes à l’intérieur. Choisir uniquement des attaques plus puissantes peut améliorer la réaction sans pour autant contribuer à la récupération. Aucune action isolée ne permet de remporter la partie.

Il en va de même pour la sécurité des logiciels.

Le modèle de sécurité derrière Breach

Le jeu tel qu’il est implémenté conserve délibérément un modèle simplifié :

Le code renforce le modèle. sim.gd dispose d’une simulation à pas de temps fixe, distincte de l’interface. Chaque portail ouvert génère des ennemis ; un portail scellé cesse temporairement d’en générer. La pression augmente à 25, 60 et 85 secondes. La fonction « Auto-Scan » sélectionne l’ennemi le plus proche se trouvant à portée. Les ennemis vaincus rapportent des jetons, et l’atteinte d’un seuil met la simulation en pause pour l’une des trois améliorations sélectionnées au hasard parmi « Pare-feu », « Taux de balayage », « Quarantaine » et « Réparation ».

Le joueur doit constamment répartir une ressource limitée : son attention.

La détection n’est pas la prévention

La fonction « Auto-Scan » est intentionnellement réactive. Elle nécessite qu’une cible existe, se trouve à portée et reste accessible suffisamment longtemps pour qu’un tir puisse l’atteindre. Le scan aide à contrôler l’essaim, mais il ne ferme pas le portail qui l’a généré.

Cette distinction est importante en environnement de production. La validation des entrées, le principe du privilège minimal, les restrictions réseau et les dépendances corrigées peuvent empêcher ou limiter certaines catégories d’attaques. La journalisation, les métriques, les traces, la détection d’anomalies et les alertes de sécurité aident à révéler qu’un événement s’est produit. La détection peut réduire le délai entre l’intrusion et la réponse ; elle ne peut pas rendre l’intrusion impossible a posteriori.

Une bonne surveillance nécessite également plus que la simple collecte de texte. Un événement de sécurité utile indique quand, où, qui et quoi. Les échecs d’authentification, les refus d’autorisation, la validation suspecte de jetons, les changements de privilèges, les exportations et les modifications de configuration sont généralement plus utiles qu’un flot indifférencié de sorties de débogage. Les recommandations de l’OWASP en matière de journalisation mettent également en garde contre le « brouillard d’alarmes » : des événements excessifs et mal classés peuvent masquer le signal qu’ils étaient censés révéler.

Les journaux constituent en eux-mêmes des actifs sensibles. N’y consignez pas de mots de passe, d’identifiants de session, de jetons d’accès, de clés privées ou de corps de requêtes complets. Protégez les journaux contre toute modification, restreignez leur accès, définissez leur durée de conservation et reliez les alertes graves à un processus de réponse aux incidents. Un tableau de bord dont personne n’est responsable n’est qu’une décoration, pas un outil de détection.

Une violation condense cette boucle de rétroaction en un signal d’alerte et un flash indiquant les dégâts. Les systèmes réels ont besoin d’une boucle plus longue :

observer → identifier → trier → contenir → remédier → vérifier → tirer des enseignements

Chaque portail ouvert est une surface d’attaque

La surface d’attaque est l’ensemble des points accessibles où un attaquant peut interagir avec un système ou l’influencer. Un panneau d’administration accessible depuis Internet en fait partie. Il en va de même pour un analyseur de fichiers téléchargés, un callback OAuth, un sous-domaine oublié, un travailleur disposant de privilèges excessifs, un plugin Composer, un jeton CI et un service interne accessible après la compromission d’un autre composant.

Breach rend l’exposition spatiale. Trois portails ouverts génèrent plus de pression qu’un seul. Fermer un portail réduit le rythme auquel de nouvelles menaces pénètrent, même si les adversaires déjà présents dans l’arène restent dangereux.

Une véritable réduction de l’exposition suit la même direction, mais pas les mêmes mécanismes :

• Supprimez les points de terminaison, paquets, services, comptes et chemins réseau inutilisés.
• Protégez l’administration par une authentification forte et un accès réseau restreint.
• N’accordez aux processus, aux utilisateurs de bases de données, aux jetons API et aux personnes que les autorisations dont ils ont besoin.
• Séparez le traitement des requêtes publiques des plans de contrôle internes.
• Dressez l’inventaire de ce qui est exposé, car un portail inconnu ne peut être ni priorisé ni fermé.

Réduire la surface d’attaque ne rend pas un composant sûr. Cela réduit le nombre d’opportunités et limite souvent le rayon d’impact. C’est précieux, car les défenseurs ne disposent jamais d’un temps d’analyse, d’une capacité de correctifs ou d’une équipe d’intervention en cas d’incident illimités.

Appliquer des correctifs sous pression

Dans le jeu, « Patch » est le nom d’une décision de mise à niveau. « Firewall » étend le bouclier du joueur, en limitant la portée et la durée de protection. « Scan Rate » augmente la portée, la vitesse, les dégâts et la fréquence. « Quarantine » ralentit périodiquement les menaces à proximité. « Mend » restaure l’intégrité du noyau et la régénère brièvement.

Il s’agit là de choix de configuration compréhensibles. Ce n’est pas ainsi que fonctionnent les correctifs logiciels.

Un véritable correctif modifie le code ou la configuration pour corriger un défaut. Son application implique l’identification, des tests de compatibilité, le déploiement, la planification de la restauration et la vérification. Une mise à jour de dépendance peut combler une vulnérabilité tout en introduisant un changement rompant. Une mesure d’atténuation peut réduire l’exposition sans supprimer le code vulnérable. Le délai entre la divulgation publique et la correction effective constitue une fenêtre d’exposition, et les attaquants en profitent également.

L’écosystème PHP en a fourni un exemple frappant le 21 octobre 2026. PHP a publié des correctifs pour deux vulnérabilités critiques permettant l’exécution de code à distance. L'alerte du CERT-FR répertoriait les branches corrigées comme étant PHP 8.2.35, 8.3.36, 8.4.27 et 8.5.12, signalait l’existence de preuves de concept publiques pour certains déploiements spécifiques et recommandait la migration vers une version maintenue et entièrement mise à jour. Le compte-rendu de la Fondation PHP est tout aussi instructif : la détection, le triage, la coordination, la correction, la mise en paquet et la communication d’une vulnérabilité relèvent d’un système humain, et non d’un simple clic.

Pour une équipe chargée d’une application, la gestion des dépendances doit donc être continue :

composer validate --strict
composer audit --locked
composer outdated --direct

La commande composer audit vérifie les paquets installés ou verrouillés par rapport aux politiques recommandées et signale les paquets vulnérables, abandonnés ou signalés comme contenant des logiciels malveillants. Exécutez-la en CI et selon un calendrier défini, et non pas seulement lorsque quelqu’un y pense. Consultez la base de données des avis de sécurité de GitHub et OSV lors de l’examen d’un rapport, puis vérifiez l’accessibilité et les recommandations du fournisseur.

La gravité à elle seule ne détermine pas l’ordre de priorité. La hiérarchisation tient compte à la fois de la gravité, de l’exploitabilité, de l’exposition sur Internet, des exploitations existantes, des données et processus métier affectés, des contrôles compensatoires disponibles, du coût de la remédiation et du coût du retard. Un problème de gravité moyenne sur un point de terminaison d’authentification public peut mériter davantage d’attention qu’un problème critique dans un outil de développement inaccessible. Consignez la décision ; n’ignorez pas l’avis en silence.

C’est l’écran de mise à niveau de Breach transposé en termes d’ingénierie : faites votre choix en fonction de la menace qui pèse sur le système, de l’état du noyau et de ce que la minute suivante est susceptible d’apporter.

Défense en profondeur

Il n’existe pas de contrôle parfait à lui seul. La défense en profondeur part du principe que les contrôles peuvent échouer indépendamment les uns des autres et met en place des barrières avant, pendant et après une compromission.

Pour une application Symfony, une requête peut traverser des restrictions TLS et réseau, un pare-feu d’authentification, un contrôle CSRF, une validation des entrées, un mécanisme d’autorisation, une requête de base de données paramétrée, un encodage de sortie, la journalisation de sécurité, et enfin une réponse comportant des en-têtes de navigateur restrictifs. Les sauvegardes et les procédures de restauration se situent en dehors de ce chemin de requête, mais déterminent néanmoins si un incident devient permanent.

Chaque couche répond à une question différente :

• Authentification : qui est à l’origine de cette requête ?
• Autorisation : cette identité est-elle autorisée à effectuer cette action sur cet objet ?
• Validation : les données saisies sont-elles acceptables pour l’opération ?
• Interprétation sécurisée : des données non fiables peuvent-elles modifier une requête, un modèle, une commande ou la structure d’un journal ?
• Confinement : si une couche échoue, à quoi le processus ou l’identifiant peut-il accéder ?
• Détection et réponse : la défaillance sera-t-elle détectée, examinée et maîtrisée ?
• Récupération : les services et données fiables peuvent-ils être restaurés ?

Breach exprime cela à travers le déplacement, l’analyse, le verrouillage, le ralentissement, le repoussement des ennemis à l’aide d’un pare-feu et la restauration de l’intégrité. Aucune de ces mesures ne remplace les autres. Le jeu appelle cela la survie. L’ingénierie de la sécurité appelle cela la réduction des risques par couches.

Sécuriser PHP et Symfony en pratique

Commencez par un environnement d’exécution et une branche de framework pris en charge. PHP publie un calendrier de support explicite ; Symfony publie les versions maintenues et les dates de fin de support. Les versions correctives font partie de la base de référence en matière de sécurité. Une application ne peut pas compenser indéfiniment les failles d’un interpréteur ou d’un framework qui ne bénéficie plus de correctifs.

Symfony fournit des paramètres par défaut et des composants sécurisés utiles, mais la configuration reste le moyen d’exprimer la politique de sécurité. Une base de référence compacte pourrait ressembler à ceci :

# config/packages/security.yaml
security:
    password_hashers:
 Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'

    firewalls:
 main:
 lazy: true
 login_throttling:
 max_attempts: 5
 interval: '1 minute'

 access_control:
 - { path: '^/admin', roles: ROLE_ADMIN }

# config/packages/framework.yaml
framework :
    csrf_protection : true
    session :
    cookie_secure : true
    cookie_httponly : true
    cookie_samesite : lax

Le hachage de mot de passe auto permet à Symfony de sélectionner un algorithme approprié et prend en charge le rehachage à mesure que les recommandations évoluent. La limitation des tentatives de connexion augmente le coût d’une attaque par force brute, mais la documentation sur le limiteur de débit de Symfony est claire : la limitation au niveau de l’application ne constitue pas un bouclier contre les attaques par déni de service, car PHP et Symfony ont déjà démarré. Mettez en place une protection volumétrique à un niveau plus abordable, tel que le serveur web, le proxy inverse, le CDN ou le pare-feu.

L’authentification doit être suivie d’une autorisation. Un utilisateur connecté n’est pas automatiquement autorisé à modifier tous les enregistrements. Les « voters » de Symfony centralisent la politique au niveau des objets, tandis que les jetons CSRF empêchent les actions du navigateur modifiant l’état d’être déclenchées par une autre origine :

use Symfony\Component\ExpressionLanguage\Expression;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Security\Http\Attribute\IsCsrfTokenValid;
use Symfony\Component\Security\Http\Attribute\IsGranted;

#[IsGranted('PROJECT_DELETE', 'project')]
#[IsCsrfTokenValid(
    new Expression('"delete-project-" ~ args["project"].getId()'),
    tokenKey: '_token',
    methods: ['POST'],
)]
public function delete(Project $project): Response
{
    // Supprimer uniquement si les deux vérifications aboutissent.
}

Les mesures de protection contre l'injection doivent être mises en place là où les données sont transmises à un interpréteur. Liez les valeurs au lieu de les concaténer dans du DQL ou du SQL :

$projects = $repository->createQueryBuilder('p')
    ->andWhere('p.owner = :owner')
    ->setParameter('owner', $user)
    ->getQuery()
    ->getResult();

La liaison des paramètres protège la position des valeurs. Les noms de colonnes dynamiques ou les sens de tri nécessitent toujours une liste blanche, car les paramètres ne peuvent pas représenter en toute sécurité les identifiants SQL. Dans les modèles, conservez l’échappement contextuel automatique de Twig activé ; vérifiez chaque utilisation de |raw. Validez les données d’entrée structurées, mais ne confondez pas la validation avec la prévention des injections SQL ou des attaques XSS : chaque point de sortie doit disposer de sa propre API sécurisée et de son propre contexte d’encodage.

Les secrets doivent provenir d’un gestionnaire de secrets de déploiement ou du coffre-fort de secrets chiffrés de Symfony, jamais du contrôle de version. La clé de déchiffrement de production doit être stockée séparément et renouvelée en cas de suspicion d’exposition. Les sessions doivent utiliser HTTPS, les attributs Secure, HttpOnly et une politique SameSite appropriée ; régénérez l’identifiant de session après un changement de privilèges ou une connexion. Les API nécessitent une validation explicite du public cible, de l’émetteur, de la date d’expiration et de la portée du jeton — et pas seulement un JWT qui s’analyse.

Lors du déploiement, effectuez l’installation à partir du fichier de verrouillage, excluez les dépendances de développement, vérifiez les exigences de la plateforme, désactivez le mode débogage, limitez les répertoires accessibles en écriture, exécutez les workers sous des identités disposant du moins de privilèges possible et limitez la racine Web à public/. Ajoutez des en-têtes tels que la politique de sécurité du contenu (Content Security Policy), HSTS, frame-ancestors et une politique de référent prudente au niveau de l’application ou de la périphérie, puis testez la réponse obtenue plutôt que de vous fier aveuglément au fichier de configuration.

Il ne s’agit pas d’une liste de contrôle à remplir puis à oublier. C’est un ensemble de contrôles interdépendants qui doivent rester observables, corrigés, testés et gérés.

Du SSO personnalisé à OpenID Connect

Les protocoles d’authentification constituent un domaine particulièrement coûteux pour l’élaboration de règles locales. La validation des redirections, la protection contre les attaques CSRF, l’interception des codes d’autorisation, la rotation des clés de signature, les audiences des jetons, la relecture des nonces, la déconnexion et la gestion des erreurs créent une surface d’attaque plus vaste que ne le laisse supposer à première vue une simple « redirection de connexion ».

OpenID Connect ajoute une couche d’identité à OAuth 2.0. Dans un flux de navigateur moderne, l’application redirige l’utilisateur vers un fournisseur d’identité, reçoit un code d’autorisation à durée de vie limitée, l’échange au niveau du point de terminaison des jetons et valide un jeton d’identité signé. PKCE S256 lie le code à un vérificateur à haute entropie détenu par le client. La découverte publie les métadonnées du fournisseur ; JWKS publie les clés de signature publiques. Le client doit toujours valider la signature et les revendications telles que l’émetteur, l’audience, l’expiration, la partie autorisée et le nonce. La RFC 9700 recommande l’utilisation du code d’autorisation et de PKCE, y compris pour les clients web confidentiels, et identifie S256 comme la méthode de défi qui n’expose pas le vérificateur.

Les normes n’éliminent pas le travail de sécurité. Elles le concentrent dans des spécifications révisées et des bibliothèques maintenues, rendent explicites les vérifications attendues et permettent à des outils interopérables de tester le résultat. Remplacer un protocole personnalisé par l’OIDC réduit la quantité de comportements d’authentification qu’une équipe d’application doit concevoir et défendre seule.

Ce que la conception de jeux vidéo nous apprend sur la sécurité

Une faille rend lisibles les propriétés invisibles du système.

Un portail ouvert clignote en magenta. Un portail scellé vire au bleu sarcelle et affiche le temps restant. L’anneau du Noyau évolue en fonction de l’intégrité. Les formes des ennemis indiquent des comportements différents. La courbe de pression laisse au joueur le temps d’apprendre avant de l’obliger à faire des choix plus difficiles. Les outils de sécurité ont besoin de la même clarté : une alerte doit nommer la ressource, la preuve, la gravité et le propriétaire ; une mesure corrective doit indiquer si l’exposition persiste ; un incident doit avoir un état actuel.

Le jeu révèle également la valeur et le danger de l’abstraction.

L’intégrité du Noyau combine plusieurs résultats en un seul chiffre. La véritable sécurité sépare la confidentialité, l’intégrité et la disponibilité. La « Breach » (violation) représente fortement l’intégrité et la disponibilité : des entités hostiles corrompent le « Core » et peuvent mettre fin au service. Elle ne représente pratiquement pas la confidentialité : des données pourraient être copiées alors que le « Core » affiche toujours 100. « Mend » (réparation) ressemble à une récupération, mais une véritable récupération implique des sauvegardes testées, des procédures de restauration, des identifiants reconstitués, une confiance en l’expertise numérique et des enseignements réinjectés dans la prévention.

De même, un ennemi « zero-day » est simplement lent, tenace et destructeur. Un véritable « zero-day » se définit par l’absence de correctif disponible pour les défenseurs, et non par un nombre plus élevé de points de vie. Ce terme établit une hiérarchie lisible des menaces ; il ne doit pas véhiculer une fausse définition technique.

Ce qui est transmis, c’est la structure décisionnelle. Sous pression, les défenseurs doivent choisir entre mettre fin à un incident en cours, réduire un point d’entrée exposé, appliquer une mesure corrective, préserver le service et investir dans une détection future plus efficace. Les bons programmes de sécurité font ces choix avant les dernières secondes : ils inventorient les actifs, répètent les interventions, testent la reprise et définissent la responsabilité des risques tant que le terrain est encore calme.

La sécurité est un jeu continu

Darkwaar40 — « Breach » dure 100 secondes parce qu’un jeu a besoin d’une fin. Un système de production, lui, n’en a pas.

Un nouveau code modifie la surface d’attaque. De nouvelles dépendances entraînent de nouveaux avis de sécurité. Les identifiants vieillissent et font l’objet de fuites. Les règles de détection évoluent. Les équipes changent. Un contrôle qui fonctionnait au moment du déploiement peut devenir obsolète sans qu’aucune défaillance spectaculaire n’apparaisse à l’écran.

La leçon durable n’est pas « scanner plus intensément » ou « appliquer tous les correctifs instantanément ». Il s’agit de mettre en place une boucle : savoir ce qui est exposé, prévenir ce qui peut l’être, détecter ce qui franchit la frontière, hiérarchiser en fonction de la probabilité et de l’impact métier, contenir les incidents, rétablir les services fiables et améliorer le système à la lumière de ce qui s’est passé.

Dans Breach, le joueur ne cesse d’avancer, car rester immobile laisse les portails décider du déroulement de la partie.

L’ingénierie de la sécurité obéit à la même règle.

Jouez à Darkwaar40 — Breach sur darkwaar.com.

Références

• PHP : versions prises en charge
• La Fondation PHP : la mise à jour de sécurité PHP d'aujourd'hui et comment nous renforçons la sécurité de PHP
• CERT-FR : Plusieurs vulnérabilités dans PHP — CERTFR-2026-ALE-014
• Versions de Symfony
• Documentation sur la sécurité de Symfony
• Symfony : hachage et vérification des mots de passe
• Symfony : protection CSRF
• Symfony : gestion des secrets
• Symfony : limiteur de débit
• Symfony 8.2 : connexion via OpenID Connect
• Composer : commande audit
• Sécurité de l'ORM Doctrine
• Norme OWASP de vérification de la sécurité des applications
• Aide-mémoire OWASP sur la journalisation
• Méthodologie de notation des risques de l’OWASP
• Base de données des avis de sécurité de GitHub
• OSV : Vulnérabilités open source
• Meilleures pratiques actuelles en matière de sécurité OAuth 2.0 — RFC 9700
• Proof Key pour l'échange de code — RFC 7636
• OpenID Connect Core 1.0
• OpenID Connect Discovery 1.0