Threat Modeling Example: A Cybersecurity Portfolio Exercise

This threat modeling example follows a small fictional booking app from a user's browser to its database and email provider. You'll map the data flow, use STRIDE to ask what could go wrong, then turn one concern into a requirement and a test you can explain.

Treat it as a learning exercise, not a security assessment or proof of production experience. Keep the sample data fictional. A real system model needs people who understand its design, users, infrastructure, and business decisions. The CMS Threat Modeling Handbook outlines system, stakeholder, and infrastructure inputs for teams doing that work.

What system are we modeling?

Imagine a community workshop site. A visitor chooses a session, enters a name and email address, and submits a booking. The app checks capacity, stores the booking, and asks an outside email service to send a confirmation with a booking-management link. Staff sign in to a separate page to review registrations and change session capacity.

For this exercise, assume the booking service, database, and staff page are in scope. The hosting provider, a visitor's device, and the email provider's internal security controls are outside the model. That does not mean they are risk-free. It means this first pass records where the team would need more information.

The main assets are the booking record, contact details, session capacity, staff account, and the credential the app uses to contact the email provider. The OWASP threat-modeling guide recommends making the system, its flows, stores, external parties, and trust boundaries visible before listing threats.

Follow one booking through the system

Visitor's browser
    | booking request: session choice, name, email
    v
Public booking API ------> Booking database
    |
    | confirmation message and recipient
    v
External email provider

Staff browser
    | staff sign-in and capacity changes
    v
Staff API --------------> Booking database

The main trust boundaries are where a visitor's browser reaches the public API, where the app reads or writes stored bookings, where staff access management functions, and where the app sends data to an outside mail service. A data-flow diagram does not need to look polished. It needs enough detail for another person to see who sends what, to which component, and across which boundary. OWASP's DevSecOps threat-modeling guideline describes processes, stores, external entities, flows, and trust boundaries as useful parts of a right-sized diagram.

What could go wrong in this booking flow?

STRIDE gives you six prompts. Apply each to components and flows in your model, then keep the examples that fit this system. OWASP describes STRIDE as one useful technique, not the only way to identify threats.

These are prompts, not findings. You have not shown that the fictional app contains any of these weaknesses. In a real review, check the design and implementation with the people responsible for the system before calling a scenario a vulnerability.

Turn one threat into a requirement you can test

Choose the booking lookup concern because it touches personal information and can be described with a clear boundary. A weak design might let a visitor change the record identifier in the emailed management link and reach someone else's booking. That is a scenario to investigate, not a claim about a live site.

Write the requirement so a developer can tell whether the behavior is correct:

A booking lookup or cancellation must verify that the request is authorized for that booking. It must not return another visitor's name, email address, or session details when the requester changes a booking identifier.

Then make a small synthetic test matrix. Use two made-up bookings, A and B. Do not use real attendee records or send real email.

For a portfolio exercise, you can stop at the design and test plan. If you choose to build a demo, keep it local or in a controlled environment, use synthetic data, and write down which checks you actually ran. A proposed requirement is not an implemented fix, and a passing test on a small demo is not proof that a production service is secure.

What should the portfolio artifact contain?

Make the reasoning easy to review. A concise artifact can include:

1. Purpose and scope: what the fictional service does and what you chose not to model.
2. Assumptions: account model, data handled, outside services, and anything you could not verify.
3. System model: components, stores, external services, data flows, and trust boundaries.
4. Threat list: the relevant STRIDE prompts, affected component or flow, and why each scenario matters.
5. One prioritized response: the threat you chose to address first, your reason, and the requirement you would use.
6. Validation plan: the test cases, synthetic data, expected results, and what you actually executed.
7. Limits and next questions: remaining risks, out-of-scope providers, and changes that would require another review.

You can adapt this short worksheet:

System and purpose:
Data or capability worth protecting:
In-scope components and flows:
Trust boundaries:
Assumptions and excluded parts:
Threat scenario and affected component:
Why this scenario matters:
Requirement or response:
Safe test and expected result:
What I did not verify:
What would make me revisit this model:

If you discuss the work in an interview or on a resume, label it as an independent, course, or team exercise. Explain your own contribution and what you did not test. Our cybersecurity project guide has more examples of describing project evidence, and the software engineer to application security guide covers a related AppSec practice project.

What this exercise does not prove

A diagram can be wrong or incomplete if its assumptions are wrong. STRIDE can help you ask structured questions, but the acronym does not guarantee that you found every relevant issue. The model also does not replace code review, security testing, operational knowledge, or decisions from the people who own the real system.

Revisit the model if the app adds user accounts, stores payment details, changes its email integration, or gives staff new permissions. The MDN threat-modeling guide also frames threat modeling as an iterative process that depends on system scope and boundaries.

The strongest portfolio version is specific about evidence. Show the flow you drew, the assumption you questioned, and the test you ran. Don't describe a fictional design as work for a real employer or imply that a practice exercise guarantees a job.

If you're ready to connect your preparation to current openings, browse cybersecurity jobs and compare each role's actual responsibilities and requirements.