OWASP Cornucopia

OWASP Cornucopia est un jeu de cartes conçu par Colin Watson au sein de l’OWASP, inspiré d’Elevation of Privilege. Il aide les équipes de développement, notamment agiles, à identifier les exigences de sécurité d’une application web à partir d’attaques possibles. Les cartes couvrent six familles : validation et encodage des données, authentification, gestion des sessions, autorisation, cryptographie, et une couleur Cornucopia pour les autres sujets. À chaque carte jouée, l’équipe discute de la façon dont l’attaque pourrait concerner l’application étudiée, puis formule les exigences ou histoires de sécurité à traiter.

Déroulé

1. 1

   Cadrer l’application et l’objectif de sécurité

   10 à 15 min

   L’animateur ouvre l’atelier en précisant : « Aujourd’hui, nous allons utiliser les cartes OWASP Cornucopia pour explorer des attaques possibles et en déduire des exigences de sécurité concrètes. » Il fait choisir ou confirme l’application web étudiée, son périmètre fonctionnel et le niveau de détail attendu. Les participants listent rapidement les parcours utilisateurs, données sensibles, rôles, interfaces et dépendances connues. Cette étape évite de jouer dans l’abstrait : chaque carte devra ensuite être reliée à un élément réel du produit.

   Astuce — Affichez un schéma très simple de l’application, même imparfait : utilisateurs, front, back, données, systèmes tiers. Les discussions seront beaucoup plus rapides quand une carte évoquera une attaque sur une session, une autorisation ou une donnée.

2. 2

   Présenter les cartes et les familles de risques

   5 à 10 min

   L’animateur montre le paquet officiel OWASP Cornucopia sans recopier le contenu des cartes, puis explique les six couleurs : validation et encodage des données, authentification, gestion des sessions, autorisation, cryptographie, et Cornucopia pour le reste. Il précise : « Chaque carte décrit une attaque possible et renvoie à des référentiels OWASP ; nous allons nous en servir comme déclencheurs de réflexion. » Il rappelle que l’objectif n’est pas de gagner contre les autres, mais de produire de meilleures exigences. Les participants peuvent parcourir brièvement leurs cartes pour comprendre le type de formulation attendu.

   Astuce — Ne laissez pas l’équipe lire tout le paquet au début : cela dilue l’énergie. Donnez juste assez de contexte pour démarrer, puis laissez les cartes provoquer la discussion au fil du jeu.

3. 3

   Installer la mécanique de jeu

   5 min

   L’animateur installe une mécanique de type jeu de plis : un joueur pose une carte, lit ou résume l’attaque décrite, puis explique comment elle pourrait concerner l’application étudiée. Il annonce la consigne : « Pour chaque carte jouée, nous décidons ensemble si l’attaque est plausible, partiellement pertinente ou non pertinente, puis nous capturons les exigences qui en découlent. » Aucune règle de score n’est nécessaire si l’atelier vise la production d’exigences. Les participants jouent à tour de rôle afin que chacun contribue à l’analyse de sécurité.

   Astuce — Désignez dès maintenant une personne pour noter, distincte de l’animateur si possible. Si personne ne capture les décisions en direct, les meilleures exigences disparaissent dans la discussion.

4. 4

   Jouer un premier tour guidé

   10 à 15 min

   L’animateur invite un premier joueur à poser une carte et à dire : « Cette attaque pourrait nous concerner si… » en s’appuyant sur le périmètre défini. Il relance avec des questions courtes : « Où cela arriverait-il ? Quel utilisateur ou quel attaquant ? Quelle donnée serait touchée ? Quel contrôle existe déjà ? » L’équipe débat, mais l’animateur limite les digressions techniques trop détaillées. En fin de discussion, il fait formuler une exigence ou une histoire de sécurité issue de la carte, ou note explicitement que la carte est non applicable avec la raison.

   Astuce — Sur le premier tour, soyez très directif sur la formulation. Une bonne sortie ressemble à une exigence vérifiable ou à une user story de sécurité, pas à une inquiétude vague du type « faire attention à l’authentification ».

5. 5

   Enchaîner les plis et produire les exigences

   25 à 60 min

   Les joueurs continuent à poser des cartes à tour de rôle, chacun devant expliquer le lien potentiel entre l’attaque et l’application. Pour chaque carte, l’équipe décide si elle génère une exigence, une histoire de sécurité, une question ouverte, ou aucune action. L’animateur veille à couvrir les différentes couleurs du jeu : validation et encodage des données, authentification, gestion des sessions, autorisation, cryptographie et Cornucopia. Il garde le rythme en annonçant : « Nous cherchons une décision exploitable par carte, pas une conception complète de la solution. »

   Astuce — Utilisez quatre colonnes visibles : Carte, scénario d’attaque, exigence ou story, statut. Le statut peut rester simple : à traiter, à clarifier, déjà couvert, non applicable.

6. 6

   Consolider et prioriser les sorties

   10 à 20 min

   Quand le temps de jeu est écoulé, l’animateur arrête les nouvelles cartes et relit les exigences produites. Il demande : « Qu’est-ce qui doit entrer dans le backlog, qu’est-ce qui nécessite une clarification, et qu’est-ce qui est déjà couvert par nos pratiques actuelles ? » Les participants regroupent les doublons et reformulent les éléments trop vagues. L’objectif est de sortir avec une liste actionnable d’exigences ou d’histoires de sécurité liées à l’application, et non avec un simple compte rendu de discussion.

   Astuce — Gardez les références aux cartes jouées à côté des exigences. Elles aideront ensuite à justifier l’exigence auprès d’un product owner, d’un architecte ou d’une équipe qui n’a pas participé.

7. 7

   Clore par l’apprentissage et les suites

   10 à 15 min

   L’animateur anime un débrief court en revenant sur ce que le jeu a révélé : angles morts, hypothèses implicites, contrôles déjà en place et sujets à approfondir. Il demande à l’équipe de choisir les prochaines actions : création de tickets, revue d’architecture, clarification fonctionnelle, test de sécurité ou ajout d’un critère d’acceptation. Il rappelle que les cartes renvoient à des référentiels OWASP, utiles pour approfondir les exigences identifiées. La session se termine par un engagement clair sur qui reprend la liste et comment elle sera intégrée au travail produit.

   Astuce — Terminez toujours par un propriétaire et une date de reprise pour les sorties. Sans ce passage de relais, Cornucopia reste un bon atelier de sensibilisation mais perd sa valeur opérationnelle.

Variantes

• Version backlog agile : après chaque carte pertinente, l’équipe rédige immédiatement une user story de sécurité ou un critère d’acceptation, puis l’ajoute à une colonne dédiée pour affinage après l’atelier.
• Version revue d’architecture : avant de jouer, l’équipe affiche un schéma applicatif. Pour chaque carte, elle place l’attaque sur le composant concerné afin de visualiser les zones les plus exposées.
• Version sensibilisation courte : limiter le nombre de cartes jouées et privilégier la discussion qualitative. L’objectif devient de faire découvrir les familles de risques OWASP plutôt que de produire un backlog exhaustif.
• Version à distance : utiliser un tableau collaboratif pour les colonnes Carte, scénario, exigence et statut, et faire jouer les participants à tour de rôle en visioconférence avec le paquet officiel disponible côté animateur ou via le support officiel autorisé.