Threat Modeling an Online Store — Part 1 : Understanding Data Flows, Trust Boundaries, and Security Risks.
What happens behind the scenes when a customer purchases a product from an online store?
A customer may simply browse products, add an item to a cart, make a payment, and receive an order confirmation. However, several components work together behind that experience.
The Web Application processes requests, the Authentication Service validates identities, the SQL Database stores application information, and an external Payment Gateway handles payment processing.
From an application security perspective, understanding how these components communicate is an important first step towards identifying potential threats.
In this article, I’ll walk through the Data Flow Diagram (DFD) of ShopSphere, a fictional e-commerce application, using Microsoft Threat Modeling Tool.
The focus is on understanding the elements in the diagram, following the data flows between them, examining the trust boundaries, and identifying the security questions that arise from those interactions.
1. Understanding the ShopSphere architecture
Before examining the individual data flows, let’s understand the components represented in the DFD.
ShopSphere allows customers to browse products, manage shopping carts, make payments through a third-party provider, and view their orders. Administrators manage inventory and product prices.
The architecture contains three external entities, three processes, and one data store.
External entities
External entities represent people or systems that interact with the application from outside the processes being modelled.
Customer
The customer interacts with the Web Application to browse products, manage a cart, authenticate when required, make purchases, and access order information.
Admin
The administrator interacts with the Admin Interface to perform administrative operations, including inventory and product-price management.
Payment Gateway
The Payment Gateway is an external third-party service that processes payments initiated by ShopSphere.
Processes
Processes represent components that perform operations on information.
Web Application
This handles the main application functionality. It receives requests, processes application operations, and communicates with the Authentication Service, SQL Database, and Payment Gateway.
Authentication Service
This component validates user identity when authentication is required and returns the relevant authentication result.
Admin Interface
This provides the administrative interface through which administrators access management functionality.
Data store
SQL Database
The database stores application information, including customer details, product information, and order records.
These components form the foundation of the ShopSphere DFD.
2. Understanding the customer-to-Web Application flow
Let’s begin with the first interaction in the customer journey.
The customer interacts with the Web Application.
Consider a customer visiting ShopSphere to purchase a laptop.
The customer sends requests to the Web Application to browse available products, view product details, and manage their shopping cart.
The Web Application receives these requests and processes them before returning the appropriate responses.
This interaction is important because the Web Application is the entry point for customer-facing functionality.
From a security perspective, requests received from the customer should be treated as untrusted input.
For example, a customer could modify a request before sending it to the server. They might change a product identifier, quantity, or price.
The application must therefore validate incoming requests and independently determine values that should be controlled by the server.
Security question: Does the Web Application trust information supplied by the customer’s browser, or does it validate and retrieve authoritative information on the server side?
3. Understanding the Web Application and Authentication Service flow
Next, let’s examine the interaction between the Web Application and the Authentication Service.
When a customer attempts to access functionality that requires authentication, the Web Application communicates with the Authentication Service.
The Authentication Service validates the supplied credentials or session token and returns the authentication result and relevant identity information to the Web Application.
The Web Application then uses this result when processing the customer’s request.
It is important to understand the direction of this interaction:
- The customer submits an authentication request through the Web Application.
- The Web Application communicates with the Authentication Service.
- The Authentication Service validates the authentication information.
- The Authentication Service returns the result to the Web Application.
- The Web Application uses the result to determine how to handle the request.
The Authentication Service establishes whether the user has successfully authenticated. It does not automatically grant permission to perform every operation.
For example, a customer may successfully authenticate but still must not be allowed to access another customer’s order.
This brings us to an important distinction:
- Authentication: Establishes who the user is.
- Authorization: Determines what the authenticated user is allowed to do.
In this model, authorization checks are responsibilities of the Web Application. The DFD does not represent a separate Authorization Service.
Security question: Can an attacker impersonate another user, or can an authenticated user access functionality beyond their permitted privileges?
4. Understanding the Web Application and SQL Database flow
The next important connection is between the Web Application and the SQL Database.
The Web Application communicates with the database to retrieve and update information needed by the application.
For example, when a customer browses products, the application needs product information such as descriptions, prices, and inventory availability.
When a customer places an order, the application also needs to work with order-related information.
The database is therefore an important component in maintaining the application’s information.
Consider a customer attempting to purchase a laptop.
The browser may submit a product identifier and quantity as part of the checkout request. However, the application should not simply accept a price supplied by the browser.
Instead, the Web Application should retrieve the authoritative product price from the SQL Database and use that value when calculating the order.
This is important because an attacker could manipulate client-side values before submitting a request.
For example, changing the displayed price in the browser does not mean the server should accept the modified price.
The Web Application must maintain control over important business data and ensure that unauthorized users cannot modify protected records.
Security questions:
- Can a customer manipulate product prices?
- Can one customer retrieve another customer’s order?
- Can unauthorized requests modify order information?
- Is database access restricted to the components and operations that need it?
This flow is particularly important when considering data integrity, confidentiality, and access control.
5. Understanding the Web Application and Payment Gateway flow
Now let’s examine one of the most important interactions in the ShopSphere architecture: communication with the external Payment Gateway.
When a customer proceeds to checkout, the Web Application communicates with the Payment Gateway to initiate payment.
The application sends the necessary payment request information to the external provider.
The Payment Gateway processes the request and returns payment response information to the Web Application.
This interaction is represented in the DFD as communication between the Web Application and an external entity.
Let’s follow the logical sequence:
- The customer proceeds to checkout.
- The Web Application prepares the payment request.
- The Web Application communicates with the Payment Gateway.
- The Payment Gateway processes the payment.
- The Payment Gateway returns payment response information.
- The Web Application must verify the payment result before updating the order as paid.
The last step is particularly important.
Get Ibekwe Victor’s stories in your inbox
Join Medium for free to get updates from this writer.
ShopSphere should not blindly trust a payment response simply because it appears to come from an external provider.
The application needs a reliable verification mechanism. Depending on the provider’s integration, this could involve verifying a signed callback, checking the transaction reference, validating the expected amount and currency, or confirming the transaction directly with the provider.
These are recommended security considerations; the DFD represents the interaction with the Payment Gateway but does not separately draw every verification operation.
Another concern is availability.
If the Payment Gateway becomes unavailable, customers may be unable to complete checkout.
The application must also handle failed, delayed, or repeated payment notifications safely.
Security questions:
- Can an attacker forge a payment confirmation?
- Does the application verify the transaction before marking an order as paid?
- Can duplicate payment notifications cause duplicate processing?
- What happens if the Payment Gateway becomes unavailable?
The external payment dependency makes this flow particularly important to examine during threat analysis.
6. Understanding the administrator data flows
The administrator journey involves a different set of interactions.
In the DFD, the Admin interacts with the Admin Interface, which communicates with the Web Application.
Let’s use an example: an administrator wants to update the price of a laptop.
Admin to Admin Interface
The administrator accesses the Admin Interface to perform management operations.
The interface provides access to the administrative functionality available in ShopSphere.
Admin Interface to Web Application
When the administrator performs an action, the Admin Interface sends the relevant request to the Web Application.
For example, the request might involve updating a product price or changing inventory information.
The Web Application receives and processes the request.
Web Application and Authentication Service
When authentication is required, the Web Application communicates with the Authentication Service to validate the administrator’s identity.
The authentication result is returned to the Web Application.
However, successfully authenticating an administrator does not mean every administrative operation should automatically be permitted.
The Web Application must also enforce the appropriate authorization checks.
For example, a regular customer should not be able to update product prices simply by discovering an administrative endpoint.
Web Application and SQL Database
After the necessary checks, the Web Application processes the administrative operation and interacts with the SQL Database to retrieve or update the relevant information.
For example, when an authorized administrator changes a product price, the application updates the corresponding database record.
This flow highlights the importance of protecting administrative functionality and maintaining the integrity of stored information.
Security questions:
- Can a regular customer invoke administrative endpoints?
- Can an administrator perform actions beyond their assigned permissions?
- Can unauthorized users modify inventory or product prices?
- Are administrative operations properly validated and recorded?
The key lesson is that administrative access must be enforced by the Web Application, not simply hidden behind the Admin Interface.
7. Understanding the trust boundaries
After examining the main interactions, we also need to understand the trust boundaries represented in the diagram.
A trust boundary highlights a separation between components or environments with different trust assumptions.
When information crosses a trust boundary, we need to consider how it is validated, protected, and authorized.
The ShopSphere DFD identifies three trust boundaries.
Internet Boundary
This boundary highlights the separation between the application and external users.
Customer and administrator requests originate outside the application environment.
This means incoming requests should be treated as untrusted.
Security considerations include input validation, authentication, authorization, secure communication, and rate limiting.
Database Trust Boundary
This boundary highlights the separation around the SQL Database.
The database contains important application information, including customer details, products, and orders.
Unauthorized access or modification could affect the confidentiality and integrity of this information.
Security considerations include restricted database access, parameterized queries, appropriate access controls, and protection of sensitive records.
Third-Party Boundary
This boundary separates ShopSphere from the external Payment Gateway.
The payment provider operates outside the application’s direct control.
Consequently, the application must establish trust in the information it receives from the provider rather than accepting it blindly.
Security considerations include payment verification, transaction validation, secure communication, and handling provider outages.
These boundaries help us identify where trust assumptions need to be examined during threat modelling.
8. From data flows to potential security threats
Now that we understand how the components interact, we can begin translating the DFD into security questions.
The ShopSphere scenario highlights six challenges:
Security challengeWhat we need to investigateProduct price or order manipulationCan a customer tamper with business data?Access to another customer’s orderAre object-level permissions enforced?Unauthorized administrative accessCan a regular user gain elevated privileges?Forged payment confirmationDoes the application verify payment responses?Payment or application outageCan a dependency failure disrupt checkout?Sensitive information in logsCould confidential information be exposed?
These questions connect the application’s architecture to potential security weaknesses.
For example:
- Manipulating product prices raises concerns about Tampering.
- Accessing another customer’s order raises concerns about Information Disclosure.
- Forging payment notifications raises concerns about Spoofing.
- Invoking administrative operations without permission raises concerns about Elevation of Privilege.
- Making checkout unavailable raises concerns about Denial of Service.
- Insufficient evidence of administrative or payment-related actions raises concerns about Repudiation.
This is where the DFD becomes useful as the foundation for a structured threat analysis.
9. What comes next: Applying STRIDE
With the ShopSphere DFD established and the major data flows understood, the next stage is applying the STRIDE methodology.
STRIDE provides six categories for identifying potential threats:
- Spoofing: Pretending to be another user or system.
- Tampering: Unauthorized modification of data.
- Repudiation: Denying an action without sufficient evidence to establish what happened.
- Information Disclosure: Exposing information to unauthorized parties.
- Denial of Service: Making an application or service unavailable.
- Elevation of Privilege: Gaining permissions beyond those legitimately granted.
The next stage will examine the individual components and data flows to identify relevant threats, assess their potential impact, and consider suitable mitigations.
The aim is to move beyond understanding how the application works and begin analysing how it could be attacked.
Conclusion
A Data Flow Diagram provides more than a visual representation of an application’s architecture.
It helps us follow information from its source to the components that receive and process it, understand where information is stored, identify external dependencies, and recognise where trust changes.
In ShopSphere, a simple customer purchase involves interactions between the Customer, Web Application, Authentication Service, SQL Database, and external Payment Gateway.
The administrator journey introduces additional interactions involving the Admin Interface, Web Application, Authentication Service, and database.
Each connection raises security questions that deserve attention.
By understanding these flows before identifying threats, we establish a more structured foundation for application security analysis.
The next step is to apply STRIDE to the ShopSphere DFD and examine the potential threats associated with its components and data flows.
Constructive feedback from application security engineers and the wider cybersecurity community is welcome.
#ApplicationSecurity #AppSec #ThreatModeling #MicrosoftThreatModelingTool #DFD #STRIDE #SecurityEngineering #CyberSecurity
