What Could Possibly Go Wrong? A Practical Introduction to Threat Modelling

Imagine your team is building a feature that allows customers to send money. The interface works, the API responds correctly, and the demo goes smoothly.

But has anyone asked what happens if a customer modifies the transaction amount? What if someone submits the same request repeatedly? What if an attacker floods the endpoint with requests?

These questions go beyond whether the feature works. They ask whether it will remain secure when someone deliberately tries to misuse it.

That is where threat modelling comes in.

In my OWASP series, I recommended making threat modelling part of the design process. Let's look at what it means, why it matters, and how you can get started.

What Is Threat Modelling?

Threat modelling is a structured way to identify potential security threats, assess their risks, and decide how to address them before they become real problems.

The Threat Modeling Manifesto captures the process in four questions:

• What are we working on?
• What can go wrong?
• What are we going to do about it?
• Did we do a good enough job?

These questions provide a simple starting point. Understand the system, identify how it could be abused, choose appropriate controls, and review whether those controls are sufficient.

You do not need to predict every possible attack. You need to identify meaningful risks while there is still time to make changes.

The Building Blocks

Before identifying threats, you need to understand what you are protecting and how the system works.

A basic threat model considers:

• Assets: What needs protecting, such as customer information, transaction records, credentials, or funds.
• Threats: What could harm those assets, such as account takeover, data exposure, or service disruption.
• Trust boundaries: Where data crosses between components with different levels of trust, such as a mobile application and a backend API.
• Data flows: How information moves between users, services, databases, and external providers.
• Mitigations: The controls used to prevent, reduce, or detect threats.

For our payment feature, a simple diagram could include the mobile application, backend API, authentication service, transaction service, database, and external payment provider.

You can then trace how a transfer moves through the system and ask where something could go wrong.

Different Approaches to Threat Modelling

Threat modelling is not a single methodology. Different approaches help teams examine different kinds of risks.

Approaches based on perspective

• Asset-centric: Starts with what needs protecting, such as customer data, credentials, or transaction records.
• Attacker-centric: Considers who might attack the system, their goals, and the capabilities they might have.
• System-centric: Examines the architecture, components, connections, and data flows to identify potential weaknesses.

These perspectives can complement each other.

Common threat modelling methodologies

• STRIDE: Organises software threats into six categories. It is a useful starting point for analysing applications and APIs.
• PASTA: Connects technical threats to business risks and potential impact.
• LINDDUN: Focuses on privacy threats, particularly in systems that process personal information.
• Attack trees: Map the different paths an attacker could take to achieve a specific goal.
• OCTAVE: Focuses on organisational information security risks.
• VAST: Emphasises scalable threat modelling across development teams.
• Trike: Uses a risk-based approach to security requirements and access control.

You don't need to learn every methodology before getting started. For many development teams, STRIDE offers a practical way to begin identifying threats systematically.

These approaches are not mutually exclusive. A team might map its architecture, identify critical assets, and then use STRIDE to examine potential threats.

For development teams looking for a practical starting point, STRIDE is a useful option.

Understanding STRIDE Through a Payment Example

STRIDE is a threat modelling methodology associated with Microsoft. Its name represents six categories of security threats.

Let's apply each category to our money transfer feature.

1. Spoofing: Pretending to be someone else

An attacker impersonates a customer to initiate a transfer.

Possible mitigation: Use strong authentication and verify the customer's identity and session on the server.

2. Tampering: Modifying data without authorisation

Someone changes the transfer amount or recipient in a request.

Possible mitigation: Validate transaction details on the server and ensure the customer confirms the correct transaction.

3. Repudiation: Denying an action

A customer disputes a transfer, but the system lacks sufficient records to investigate what happened.

Possible mitigation: Maintain reliable, access-controlled audit logs with relevant transaction identifiers, timestamps, and outcomes.

4. Information disclosure: Exposing data

A customer accesses another user's transaction history.

Possible mitigation: Enforce server-side authorisation so customers can access only the records they are permitted to see.

5. Denial of service: Disrupting availability

An attacker floods the transfer endpoint with requests, preventing legitimate customers from using it.

Possible mitigation: Apply appropriate rate limits, monitor suspicious traffic, and protect service capacity.

6. Elevation of privilege: Gaining unauthorised permissions

A normal customer exploits an access control flaw to perform an administrative action.

Possible mitigation: Enforce least privilege and verify permissions for every sensitive operation.

These are not exotic attacks. They are familiar ways systems can fail when identity, data integrity, access, accountability, availability, or permissions are not handled properly. STRIDE helps teams consider these possibilities systematically rather than relying on whoever happens to be in the room to think of them.

However, identifying a threat is only the beginning. The team must decide which controls address it and verify that those controls work.

For example, rate limiting can reduce abusive traffic, but it will not fix a business logic flaw that allows an authorised customer to exploit the transfer process. Different risks require different controls.

STRIDE also does not cover every privacy concern. If a system collects phone numbers, location data, and transaction histories, LINDDUN can help identify privacy risks such as linkability and unnecessary disclosure. PASTA can help connect technical threats to their potential business consequences.

The right methodology depends on what you are building and which risks matter most.

Why Does Threat Modelling Matter?

1. It catches design flaws that security tools might miss

Code reviews, vulnerability scanners, and penetration tests are important. But they cannot replace a deliberate examination of the system's design.

Imagine a payment service that processes the same transfer request multiple times as separate transactions. The issue might not be a vulnerable library or a missing patch. It might be that the original design never accounted for duplicate requests.

Threat modelling creates an opportunity to identify that problem before implementation.

This connects to A06:2025, Insecure Design, in the OWASP Top 10. A system can be implemented as intended and still be insecure if its design does not account for important threats.

2. It helps teams prioritise risks

Not every threat deserves the same level of attention. Unauthorised transfers and exposure of financial information are likely to require more urgent action than an issue with minimal security impact.

Threat modelling helps teams consider potential impact, likelihood, existing controls, and the consequences of getting a decision wrong.

The goal is not to eliminate every conceivable risk. It is to make informed decisions about which risks to address first.

3. It brings different teams into the conversation

Developers understand the implementation. Product managers understand the user journey. Infrastructure teams understand deployment and availability. Security teams assess threats and controls.

Threat modelling brings these perspectives together.

A product manager might want a faster transfer experience, while a security engineer raises concerns about transaction confirmation. Discussing these requirements early helps the team find a design that balances usability and security.

4. It makes security part of the design process

Finding a design flaw before development usually gives a team more options than discovering it after launch, when fixing it might involve multiple services, production changes, and customer remediation.

Threat modelling does not guarantee that every flaw will be found. It creates a deliberate opportunity to identify important risks before changes become more expensive.

How to Get Started

You do not need an elaborate process or a dedicated threat modelling team to begin.

Choose one upcoming feature and follow these steps:

1. Draw the system. Map the main components, data flows, external services, and trust boundaries.
2. Identify what matters. List the data, functionality, and business processes that would cause harm if compromised.
3. Apply STRIDE. Consider spoofing, tampering, repudiation, information disclosure, denial of service, and elevation of privilege.
4. Prioritise three important risks. Focus on the threats with the most significant potential consequences.
5. Record mitigations and owners. Decide what needs to change and how the team will test the controls.
6. Revisit the model. Update it when significant changes to the architecture, integrations, or data flows introduce new risks.

What Could Possibly Go Wrong?

Returning to our money transfer feature.

A short threat modelling session might reveal the need for stronger authorisation checks, server-side transaction validation, protections against duplicate processing, rate limiting, and reliable audit logs.

Would that guarantee the system was secure? No.

Threat modelling cannot predict every attack or replace secure implementation and testing. But it can help teams identify risks that might otherwise go unnoticed until someone discovers them in production.

Cybersecurity often focuses on detecting attacks, responding to incidents, and fixing vulnerabilities. Those activities matter, but we should also ask what we can do before the code is written.

What assumptions are we making about our users? Where are our trust boundaries? What happens when a request is manipulated or repeated?

These questions belong in conversations between developers, product managers, architects, and security professionals.

The next time your team prepares to build a feature, don't wait until the penetration test to ask what could go wrong.

Ask while there is still time to change the design.

As always, keep learning, stay curious, and remember, I'm always rooting for you.