Threat Modeling a Simple Banking App

Post Cover

Threat modeling is a crucial step in designing secure systems as it highlights potential vulnerabilities and fixes them at an early stage , allowing Secure-by-design software to be developed safely and effectively.
At the time of writing of this blog , I am currently halfway through the “IriusRisk AI Practitioner“ path, I have grasped threat modeling as a concept, assimilated some new notions and seen a couple of tutorials. Well it’s time to put this into practice.

Scenario:

You are part of the Threat Modelling team for a company that has developed a new web application called “e-sectransfer.” This application allows users to perform various banking operations online, such as checking account balances, transferring funds, and paying bills. Your task is to create a threat model for this application to identify potential security risks and suggest mitigation. The results will be presented to the Threat Modelling team and to Senior Management.
(This exercise is included in the learning path mentioned above.)

Step 1 : Identify Critical Assets & Components

First of all, it would be nice to precise that Assets come in different types (data, software, human , service ..) but the ones that are generally most critical and deserve more focus are the data assets.

Assets:

  1. User Credentials : Usernames, passwords, PINs, and MFA tokens.
  2. Transaction Data : Records of transfers, payments, and deposits.
  3. Account Balances :Real-time financial information for each account.
  4. Personal Information :Names, addresses, phone numbers, emails, and IDs.
  5. API Keys / Tokens : Used for secure communication between services.
  6. Audit & Log Data : System logs and transaction history for compliance and fraud detection.

Components:

  1. Application Server : Processes business logic (transactions, authentication, account operations).
  2. Database Server : Stores user data, account balances, transaction history, and logs.
  3. API Layer : Enables communication between frontend, mobile app, and backend services.
  4. Mobile Application : Provides mobile access to banking services via API calls.
  5. Authentication & Authorization Service : Manages user login, session control, MFA, and access permissions.

Note : The Mobile App component can definitely be replaced by a web browser, which was my initial choice, but I found a literal mobile banking app among the available components and uh, just couldn’t resist. :)))

Step 2 : Data Flow Diagram of the System

Diagramming is a crucial step in the Threat Modeling process. It allows a better visualisation and therefore understanding of the system’s components, data flows and trust boundaries.
For this , I’m diving into the IriusRisk threat modeling tool , available for free (a community version I suppose), and here’s the first draft of our web app :

first diagram

A simple explanation for how the data flows within this system would be : The user interacts with the mobile application by entering their credentials to authenticate. The mobile app sends the authentication request to the API layer, which forwards it to the authentication service for verification. Once authenticated, the user initiates a bill payment request. The mobile app sends this request to the API layer, which routes it to the application server. The application server processes the request, performs the necessary business logic, and communicates with the database server to validate account details and update balances. After the database confirms the transaction, the application server sends a response back through the API layer to the mobile application, which then displays the confirmation to the user.

Step 3: Define Trust Boundaries within the system

In this step, we tackle a core issue : trust boundaries or trust zones. Typically, whenever data transitions from a trusted to an untrusted zone, problems rise and vulnerabilities are most likely to exist. Let’s dive into it:
The mobile app goes over the internet. It is the least trusted zone in my diagram. Conversely, the inner components (API, web app, and auth&auth) reside in the Business App Hosting area, a trust zone with an elevated trust level of 90%. I have however made the choice to leave my database(s) in the Azure cloud provider, trust level was good enough (60%). What could go wrong, right ?
Here is the diagram with the components mapped within their correspondent trust zone :
trust zones

Looks neat to me.

Step 4 : Threat Identification

This fundamental step to any threat modeling process involves the structured identification of potential threats and attacks following a framework here STRIDE.
STRIDE is short for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege.
For each component, we need to find possible threats under each category.

NOTE : Each framework could give different threats according to the methodology it follows.
LINDDUN (Linking, Identifying, Non-repudiation, Detecting, Data Disclosure, Unawareness and Non-compliance) framework for example, is more privacy oriented, while PASTA ( Process for Attack Simulation and Threat Analysis) enables the alignment of business objectives with technical requirements. And although “all models are wrong”, in our case STRIDE is most “useful” for its comprehensiveness and multidimensionality.

If you want to read more about the frameworks mentioned and their best uses, you can check this:
Comparing STRIDE vs PASTA vs LINDDUN

Let’s get into it:

first diagram

Mobile Application (Internet Zone)

  1. Spoofing: Stolen credentials or session tokens used to impersonate legitimate users.
  2. Tampering: Reverse engineering or modification of the mobile app to bypass security controls.

API Service (Business Application Hosting)

  1. Spoofing: Forged API requests using stolen or manipulated authentication tokens.
  2. Tampering: Parameter manipulation or injection attacks (e.g., modifying transfer amounts).
  3. Information Disclosure: Excessive data returned in API responses or verbose error messages.
  4. Denial of Service: API request flooding leading to service unavailability.

Backend Application Server

  1. Repudiation: Insufficient logging of financial transactions.
  2. Elevation of Privilege: Broken access control allowing unauthorized actions.
  3. Denial of Service: Resource exhaustion through repeated complex requests.

Authentication Service

  1. Spoofing: Credential stuffing or brute-force login attempts.
  2. Tampering: Manipulation of authentication tokens (e.g., JWT tampering).
  3. Information Disclosure: Leakage of authentication tokens or password hashes.

Cloud Database

  1. Tampering: SQL injection leading to unauthorized data modification.
  2. Information Disclosure: Data breach exposing financial and personal information.
  3. Denial of Service: Query flooding or resource exhaustion.
  4. Elevation of Privilege: Misconfigured database roles granting excessive permissions.

Critical Data Flows

Mobile App → API
  • Spoofing: Stolen tokens used to impersonate users.
  • Tampering: Modified request parameters.
  • Information Disclosure: Man-in-the-middle attacks.
  • DoS: Request flooding.
  • Elevation of Privilege: Bypassing client-side checks.
API → Backend
  • Spoofing: Forged internal API calls.
  • Tampering: Manipulated transaction data.
  • Information Disclosure: Data exposure between services.
  • DoS: Excessive internal service calls.
Backend → Database
  • Spoofing: Unauthorized service access.
  • Tampering: SQL injection.
  • Information Disclosure: Unencrypted data transmission.
  • DoS: Long-running query exploitation.

Note : This entire process can be done automatically using the IriusRisk TM Tool. I wanted to do it manually to practise and used the results of the tool as a solution.
Here is a view of the Threats and Countermeasures dashboard :
threat example

Step 5 : Risk Assessment

This is where we rate the risk of each identified threat , consider its impact on confidentiality, integrity, and availability and visualize them using a risk assessment matrix.
Here’s the final product : (didn’t exactly go through everything but you get the gist of it) :

Risk Assessment matrix:

Component Threat Likelihood Impact (CIA) Overall Risk
Mobile App Credential theft (Spoofing) High C: High, I: High High
Mobile App App tampering Medium I: High High
API Service Injection / Parameter manipulation High C: High, I: High High
API Service API flooding (DoS) Medium A: High Medium
Backend Server Broken access control Medium C: High, I: High High
Backend Server Insufficient logging (Repudiation) Medium I: Medium Medium
Authentication Service Brute-force / credential stuffing High C: High High
Authentication Service Token manipulation Medium C: High, I: High High
Cloud Database SQL Injection High C: High, I: High High
Cloud Database Data breach (misconfiguration) Medium C: Very High High
Cloud Database Query flooding (DoS) Medium A: High Medium

Step 6 : Mitigations Strategies

Finally, it’s time to suggest countermeasures for each vulnerabilitiy/threat we identified.
I relied on the ones suggested by the tool, they’re pretty thorough and have their respective priorities indicated. Here’s an example view :
countermeasures

Now all that’s left is updating the diagram, and we’re good to go !

Wrapping up

Threat modeling helps us think like an attacker before real attackers do. By using STRIDE, we were able to clearly see where the system is most vulnerable and which risks matter the most, especially when dealing with sensitive financial data.

It makes security more structured and less guesswork-based. Instead of adding protections randomly, we focus on the real weak points.

Tools like IriusRisk make this process even cooler and more practical. They help visualize threats, automate risk identification, and generate mitigation suggestions, which saves time and makes the whole analysis more organized.

In short, threat modeling turns security into a proactive design step rather than a last-minute fix.

That’s all folks! Hope this was insightful, I really enjoyed learning this and putting it into practice.
See you next Time!
Bay.

IconPlease share with your friends !
Thanks for reading !
This work is published by Beylessen Jendoubi at 2026-02-26 16:38:48
Link: Threat Modeling a Simple Banking App
This work is licensed under CC BY-NC-SA 4.0. Please indicate Beylessen's Blog when reprinting.
Logo