🏆 Module 10 · Capstone
Capstone: FinFlow Threat Model
Apply everything you've learned to model a real-world fintech application — FinFlow — a payment platform with cloud infrastructure, a REST API, OAuth login, and an AI assistant. This is a full end-to-end threat model.
Instructor Guide — Running This Capstone
Recommended format: 60-minute live session with groups of 3–4 students.
Materials needed: Whiteboard (physical or Miro/FigJam), printed system description cards.
Phases: Each phase has a timer badge showing recommended time. Work in groups, compare answers using the "Reveal Answer" buttons for facilitated discussion.
Tip: Don't reveal answers until each group presents — the disagreement and discussion is where the most learning happens.
Materials needed: Whiteboard (physical or Miro/FigJam), printed system description cards.
Phases: Each phase has a timer badge showing recommended time. Work in groups, compare answers using the "Reveal Answer" buttons for facilitated discussion.
Tip: Don't reveal answers until each group presents — the disagreement and discussion is where the most learning happens.
1FinFlow — System Description
Read the following system description carefully. Your job is to threat model it end to end.
FinFlow — Fintech Payment Platform
What it does: FinFlow allows businesses (merchants) to accept payments from customers. It provides a merchant dashboard, a payment widget that merchants embed in their websites, and a public REST API.
Key users:
Key users:
- Customers: make payments via merchant-embedded widget (not logged in to FinFlow)
- Merchants: log in to dashboard to manage payments, view analytics, configure webhooks
- FinFlow Admins: internal team, manage platform via admin portal
- React SPA dashboard (Vercel hosting)
- REST API (Node.js on AWS Lambda, behind API Gateway)
- Merchant authentication via OAuth 2.0 (Auth0)
- Payment processing via Stripe API (PCI-compliant)
- Transaction data stored in AWS RDS (PostgreSQL) — VPC, private subnet
- AI Assistant: merchants can ask "Why did this payment fail?" — uses GPT-4 with access to the merchant's transaction history and the ability to trigger refunds via a tool call
- Webhook system: FinFlow sends POST requests to merchant-configured URLs on payment events
- CI/CD: GitHub Actions → ECR → Lambda
1
Phase 1: Scope & Asset Identification
Define your scope and identify the crown jewels
Answer these questions as a team. Write your answers on the whiteboard.
- What are FinFlow's crown jewels — the assets where a breach would be most catastrophic?
- What is out of scope for this threat model? (What are we explicitly NOT modeling?)
- Who are the threat actors — who would want to attack this system and why?
- Which regulatory frameworks apply? (PCI DSS? GDPR? SOC 2?)
Suggested Answers
Crown jewels: Merchant bank account details (payout routing), Merchant API keys (direct financial access), Transaction records (payment amounts, customer emails), Admin portal access (full platform control), Stripe integration credentials
Out of scope: Stripe's internal systems (they own that security), Vercel infrastructure, Auth0's identity systems, merchants' own websites where they embed the widget
Threat actors: (1) Financially motivated cybercriminals — redirect payouts, steal merchant bank details; (2) Competing merchants — steal analytics data; (3) Disgruntled insiders — FinFlow admin team; (4) Nation-state actors (unlikely, but possible for financial infrastructure)
Regulations: PCI DSS (card data), GDPR (EU customer emails = personal data), SOC 2 Type II (likely required by enterprise merchants)
Out of scope: Stripe's internal systems (they own that security), Vercel infrastructure, Auth0's identity systems, merchants' own websites where they embed the widget
Threat actors: (1) Financially motivated cybercriminals — redirect payouts, steal merchant bank details; (2) Competing merchants — steal analytics data; (3) Disgruntled insiders — FinFlow admin team; (4) Nation-state actors (unlikely, but possible for financial infrastructure)
Regulations: PCI DSS (card data), GDPR (EU customer emails = personal data), SOC 2 Type II (likely required by enterprise merchants)
2
Phase 2: Draw the Data Flow Diagram
Map the system — every component, flow, and trust boundary
Draw the DFD on your whiteboard. Include:
- All external entities (customers, merchants, FinFlow admins, Stripe, Auth0, merchant webhooks)
- All processes (API Gateway, Lambda functions, AI Assistant, webhook sender)
- All data stores (RDS, secrets store)
- All data flows (label each with what data moves)
- All trust boundaries (at minimum: Internet / API Zone / DB Zone / External Services)
FinFlow — Reference DFD
FinFlow Reference DFD — compare with your team's diagram. Key differences to discuss: webhook trust boundary, AI assistant tool access, and CI/CD pipeline (not shown — deliberately omitted as a teaching point)
3
Phase 3: STRIDE Threat Identification
Apply STRIDE to the most critical components
For each component below, identify at least 2 threats using STRIDE. Fill in the table:
| Component | STRIDE Category | Your Threat Description |
|---|---|---|
AI Assistant (Process 2) — with trigger_refund() tool | Write your threats here... | |
| Webhook Sender (Process 3) — POST to merchant URLs | Write your threats here... | |
| Transactions DB — contains all payment records | Write your threats here... | |
| Merchant API Keys — stored in Secrets Manager | Write your threats here... | |
| OAuth Login (Auth0 flow) | Write your threats here... |
| Component | STRIDE | Threat | Risk |
|---|---|---|---|
AI Assistant + trigger_refund() | T · E | Indirect prompt injection via transaction note field tricks AI into triggering unauthorized refunds | Critical |
| I | AI reads transaction history of ALL merchants (missing authorization check in tool call) | Critical | |
| D | Attacker floods AI endpoint with expensive queries, incurring massive GPT-4 API costs | High | |
| Webhook Sender | S | Merchant URL changed to attacker's server — FinFlow sends payment data (amounts, customer emails) to attacker | Critical |
| T · E | SSRF: merchant configures webhook URL as http://169.254.169.254/ — FinFlow's Lambda fetches AWS metadata | Critical | |
| Transactions DB | T | SQL injection via transaction search endpoint modifies payment amounts retroactively | Critical |
| I | Lambda DB role has SELECT * on all tables — compromised Lambda exfiltrates all merchant data | Critical | |
| Merchant API Keys | I | API key included in client-side JS bundle — leaked via browser DevTools | Critical |
| S | Leaked API key used to trigger payments on behalf of merchant without their knowledge | Critical | |
| OAuth / Auth0 Flow | S | Missing state parameter → CSRF attack logs merchant into attacker-controlled account | High |
| I | Access token stored in localStorage → XSS in dashboard steals token → full account takeover | High |
4
Phase 4: Risk Scoring & Prioritization
Score your top 5 threats using DREAD and build a priority list
Pick your top 5 threats from Phase 3. Score each using DREAD (1–3 per dimension) and determine priority.
| Threat | D | R | E | A | D | Total | Priority |
|---|---|---|---|---|---|---|---|
| Write your threat 1... | — | — | — | — | — | ?/15 | ? |
| Threat | D | R | E | A | D | Total | Priority |
|---|---|---|---|---|---|---|---|
| Prompt injection → unauthorized refund via AI | 3 | 2 | 2 | 2 | 2 | 11/15 | Critical |
| SSRF via webhook URL → AWS metadata | 3 | 3 | 2 | 3 | 2 | 13/15 | Critical |
| SQL injection via search → data exfiltration | 3 | 3 | 3 | 3 | 3 | 15/15 | Critical |
| API key in client JS bundle | 3 | 3 | 3 | 2 | 3 | 14/15 | Critical |
| Missing OAuth state → CSRF account link | 2 | 3 | 2 | 2 | 3 | 12/15 | Critical |
Discussion Point
Every top-5 threat scored as Critical. What does this tell us about the current security posture of FinFlow? Is this surprising given the architecture? Which one would you fix first and why?
5
Phase 5: Mitigation Planning
Design specific mitigations for your highest-priority threats
For each Critical threat, propose a specific, implementable mitigation. Be concrete — not "add security" but "add X control that does Y."
| Threat | Mitigation | Decision | Owner |
|---|---|---|---|
| Prompt injection → refund | Require human confirmation (merchant clicks "Approve" in dashboard) for ALL refunds triggered by AI. AI can only recommend refunds, not execute them. Separate refund confirmation from AI context. | Mitigate | AI team |
| SSRF via webhook URL | Validate webhook URLs against allowlist (HTTPS only, no private IP ranges, no AWS metadata). Use egress firewall on Lambda VPC to block 169.254.x.x, 10.x, 172.16.x, 192.168.x. Add delay + retry to webhook delivery to prevent timing attacks. | Mitigate | Infra team |
| SQL injection via search | Parameterized queries for all DB interactions (enforced via ORM/query builder). Enable pg_audit for query logging. Add integration test that attempts SQL injection and verifies it fails. | Mitigate | Backend team |
| API key in client bundle | Never expose API keys to frontend. All API calls from merchant dashboard go through FinFlow's own backend (BFF pattern). Merchant-facing API keys are server-side secrets only. Rotate any exposed keys immediately. | Mitigate | Frontend + Backend |
| Missing OAuth state | Add cryptographically random 256-bit state parameter to Auth0 authorization request. Validate state on callback before exchanging code for token. Auth0 SDK handles this if configured correctly — verify configuration in code review. | Mitigate | Auth team |
6
Phase 6: Debrief & Reflection
Compare findings across groups and extract lessons
Discussion Questions for the Instructor
- Which group found the most threats? What did others miss? Why?
- Did any group find the CI/CD pipeline as a threat vector? (It wasn't in the DFD — what does that tell us about scope?)
- The AI assistant has access to all merchants' transaction data via its tool. Is this a design flaw or a configuration problem? How would you redesign it?
- Which threat would have the biggest business impact if exploited? Why?
- What would need to change in FinFlow's architecture to achieve PCI DSS compliance?
Key Insight: Missed Threats Are Normal
Real threat modeling always misses some threats — that's why it's combined with penetration testing and continuous monitoring. The goal isn't perfection: it's dramatically reducing the most likely high-impact attacks before they're discovered by attackers. A threat model that finds and mitigates 80% of Critical threats is enormously valuable.
🏆Course Complete!
🎓
You've completed the Threat Modeling Guide
From the basics of what a threat model is, through STRIDE, DFDs, and real-world applications — you can now threat model basic apps, web APIs, cloud architectures, and AI agentic systems.
You Can Now:
- Answer the four questions of threat modeling for any system
- Draw a Data Flow Diagram with correct elements and trust boundaries
- Apply STRIDE per element to generate a complete threat list
- Score threats using DREAD and prioritize with a risk matrix
- Make explicit mitigation decisions and document residual risk
- Threat model basic CRUD apps, REST APIs, OAuth flows, and microservices
- Apply cloud-specific security thinking (shared responsibility, IAM, SSRF)
- Recognize and defend against prompt injection in agentic AI systems
Recommended Next Steps
Read
"Threat Modeling: Designing for Security" by Adam Shostack — the definitive book on the topic
Practice
Threat model your current project at work. Start with one feature, not the whole system
Community
OWASP Threat Modeling resources, OWASP Cornucopia cards for threat brainstorming
Certifications
OSCP, AWS Security Specialty, CISSP — all build on what you've learned here