Threat modelling a payment flow in 45 minutes with STRIDE and a whiteboard

Threat modelling has a reputation for being a heavy process with special tools and a 40 page document nobody reads. It does not have to be. For most features, a 45 minute session with the people who built it finds the important problems. This is the format I use with product teams at the bank.

Before the session (10 minutes, one person)

Draw the data flow on one page. Boxes for components, arrows for data, and dashed lines for trust boundaries, every place where data crosses from something you control to something you do not. For a typical card payment: the user's browser or app, your API, your payment service, the gateway, the ledger database, and the webhook coming back from the gateway.

In the session (35 minutes, the team)

Walk every arrow that crosses a trust boundary and ask the six STRIDE questions. Do not try to be complete. Try to be concrete.

• Spoofing. Can someone pretend to be the gateway and call our webhook? (Verify signatures. Fetch the payment from the gateway API instead of trusting the payload.)
• Tampering. Can the client change the amount? (The server computes the amount from the order. The client sends an order id, never a price.)
• Repudiation. Can an operator issue a refund and later deny it? (Audit log with actor, time and before/after values, written by the system, not by the operator.)
• Information disclosure. Where can card data or personal informations leak? (Logs, error messages, analytics events, support tools. Tokenise, mask, and read the logs of one real request.)
• Denial of service. What is expensive for us and cheap for an attacker? (The OTP endpoint: every SMS costs money. Rate limit per user and per device.)
• Elevation of privilege. Can a user act on another user's objects? (Refund, statement and card endpoints scoped by owner, with a test for each.)

Write each finding as one line with an owner. Not "improve logging security" but "mask PAN in payment-service request logs, owner: backend team, this sprint".

What usually comes out

In my experience the first session on any payment flow finds three kinds of issue almost every time: an amount or currency the client can influence, an object endpoint without an ownership check, and sensitive data in logs. None of these need a pentest to find. They need someone to ask the question with the diagram in front of them.

Keep it alive

Store the diagram next to the code and update it when the flow changes. When a new integration is added, spend 15 minutes on just the new arrows. Threat modelling is not an event, it is a habit, and a cheap habit is one that teams actually keep.