OWASP Cornucopia

OWASP Cornucopia is a card game designed by Colin Watson within OWASP, inspired by Elevation of Privilege. It helps development teams, particularly agile ones, to identify the security requirements of a web application based on possible attacks. The cards cover six families: data validation and encoding, authentication, session management, authorisation, cryptography, and a Cornucopia colour for other topics. For each card played, the team discusses how the attack could relate to the application in question, then formulates the security requirements or stories to address.

Walkthrough

1. 1

   Define the application and security objective

   10 à 15 min

   The facilitator opens the workshop by stating: "Today, we will use the OWASP Cornucopia cards to explore possible attacks and derive concrete security requirements." They confirm the web application being studied, its functional scope, and the expected level of detail. Participants quickly list user journeys, sensitive data, roles, interfaces, and known dependencies. This step prevents playing in the abstract: each card will need to be linked to a real element of the product.

   Tip — Display a very simple diagram of the application, even if imperfect: users, front end, back end, data, third-party systems. Discussions will be much quicker when a card mentions an attack on a session, an authorisation, or a piece of data.

2. 2

   Present the cards and risk families

   5 à 10 min

   The facilitator shows the official OWASP Cornucopia deck without copying the content of the cards, then explains the six colours: data validation and encoding, authentication, session management, authorisation, cryptography, and Cornucopia for the rest. They clarify: "Each card describes a possible attack and refers to OWASP references; we will use them as thought triggers." They remind participants that the goal is not to win against others, but to produce better requirements. Participants can briefly browse their cards to understand the expected type of formulation.

   Tip — Do not let the team read the entire deck at the beginning: it dilutes the energy. Provide just enough context to start, then let the cards provoke discussion as the game progresses.

3. 3

   Establish the game mechanics

   5 min

   The facilitator sets up a trick-taking game mechanic: one player plays a card, reads or summarises the described attack, then explains how it could relate to the application being studied. They announce the instruction: "For each card played, we will decide together if the attack is plausible, partially relevant, or irrelevant, then we will capture the resulting requirements." No scoring rules are necessary if the workshop aims to produce requirements. Participants take turns playing so that everyone contributes to the security analysis.

   Tip — Designate someone to take notes right away, distinct from the facilitator if possible. If no one captures decisions live, the best requirements will disappear in the discussion.

4. 4

   Play a guided first round

   10 à 15 min

   The facilitator invites the first player to play a card and say: "This attack could concern us if..." based on the defined scope. They prompt with short questions: "Where would this happen? Which user or attacker? Which data would be affected? What control already exists?" The team debates, but the facilitator limits overly detailed technical digressions. At the end of the discussion, they formulate a requirement or a security story derived from the card, or explicitly note that the card is not applicable with the reason.

   Tip — In the first round, be very directive about the formulation. A good output resembles a verifiable requirement or a security user story, not a vague concern like "be careful with authentication."

5. 5

   Chain the tricks and produce the requirements

   25 à 60 min

   Players continue to play cards in turn, each needing to explain the potential link between the attack and the application. For each card, the team decides whether it generates a requirement, a security story, an open question, or no action. The facilitator ensures that the different colours of the game are covered: data validation and encoding, authentication, session management, authorisation, cryptography, and Cornucopia. They maintain the pace by announcing: "We are looking for an actionable decision per card, not a complete design of the solution."

   Tip — Use four visible columns: Card, attack scenario, requirement or story, status. The status can remain simple: to be addressed, to clarify, already covered, not applicable.

6. 6

   Consolidate and prioritise the outputs

   10 à 20 min

   When the game time is up, the facilitator stops new cards and rereads the produced requirements. They ask: "What needs to go into the backlog, what requires clarification, and what is already covered by our current practices?" Participants group duplicates and rephrase overly vague items. The goal is to come away with an actionable list of requirements or security stories related to the application, not just a simple discussion summary.

   Tip — Keep references to the played cards next to the requirements. They will help justify the requirement to a product owner, an architect, or a team that did not participate.

7. 7

   Conclude with learning and next steps

   10 à 15 min

   The facilitator leads a short debrief by reviewing what the game revealed: blind spots, implicit assumptions, controls already in place, and topics to explore further. They ask the team to choose the next actions: creating tickets, architecture review, functional clarification, security testing, or adding an acceptance criterion. They remind that the cards refer to OWASP references, useful for deepening the identified requirements. The session ends with a clear commitment on who will take the list and how it will be integrated into the produced work.

   Tip — Always finish with an owner and a follow-up date for the outputs. Without this handover, Cornucopia remains a good awareness workshop but loses its operational value.

Variants

• Agile backlog version: after each relevant card, the team immediately writes a security user story or an acceptance criterion, then adds it to a dedicated column for refinement after the workshop.
• Architecture review version: before playing, the team displays an application diagram. For each card, they place the attack on the relevant component to visualise the most exposed areas.
• Short awareness version: limit the number of cards played and prioritise qualitative discussion. The goal becomes to introduce the OWASP risk families rather than produce an exhaustive backlog.
• Remote version: use a collaborative board for the columns Card, scenario, requirement, and status, and have participants play in turn via videoconference with the official deck available to the facilitator or through the authorised official support.