Threat Modeling for Modern SaaS Platforms


Let’s imagine we’re building a SaaS web application with the following components:
Component | Technology Stack | Responsibility |
Frontend | React / Next.js | UI for users to interact with the app |
API Gateway | NGINX or AWS API Gateway | Entry point, routing, security |
Auth Service | OAuth2, JWT | Authentication and token issuance |
User Service | Node.js / Python / Go | Handles user profile management |
Order Service | Node.js / Python / Go | Handles customer orders |
Payment Service | Stripe API | Integrates with external payment systems |
Databases | PostgreSQL (Users), MongoDB (Orders) | Data persistence per service |
Queue | RabbitMQ or Kafka | Asynchronous order processing |
Monitoring | Prometheus, Grafana, ELK | Observability and log management |
Secrets Store | HashiCorp Vault / AWS Secrets Manager | Secure secrets and key storage |
CI/CD | GitHub Actions + Kubernetes | Automation for build, deploy, release |
All services are containerized using Docker, orchestrated via Kubernetes, and deployed with GitHub Actions CI/CD pipelines.
What Are We Building? – Data Flow Diagram (DFD)
To start, we model our system using a Level 1 Data Flow Diagram (DFD) to visualize the flow of data between various components.
DFD Elements
Entities:
Users (via browser or mobile)
External Payment Provider (Stripe)
Processes:
API Gateway
Frontend App
Auth, User, Order, Payment Services
Data Stores:
PostgreSQL (User DB)
MongoDB (Orders DB)
Secrets Store (Vault)
Trust Boundaries:
Internet → Gateway
Gateway → Microservices
Microservices → DBs/Queues
CI/CD → Cluster
Data Flows
User → API Gateway (Login, Place Order)
API Gateway → Auth Service (Token Verification)
API Gateway → User Service (User Profile)
API Gateway → Order Service (Order Creation)
Order Service → Payment Provider (Charge via Stripe)
Order Service → Message Queue (Emit Order Event)
Services ↔ Databases
CI/CD → Kubernetes Cluster
Tools: OWASP Threat Dragon, Microsoft Threat Modeling Tool (TMT), draw.io, or
pytm
for code-based DFDs.
Step 2: What Can Go Wrong? – STRIDE Threat Modeling
We apply the STRIDE model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) to each key component.
Example: API Gateway
STRIDE Category | Threat | Mitigation |
Spoofing | Attacker impersonates service | Mutual TLS, JWT validation |
Tampering | API parameters modified in transit | Enforce HTTPS, input validation |
Repudiation | Logs are missing | Centralized logging with signed logs |
Information Disclosure | Sensitive data in error responses | Data classification, limit over-fetching |
DoS | Flood API with requests | WAF, rate limiting, caching |
EoP | Missing auth header allows escalation | Enforce OAuth2, strict AuthN at gateway |
Example: Payment Service
STRIDE Category | Threat | Mitigation |
Spoofing | Faked payment callbacks | Validate Stripe signatures |
Tampering | Modify order amounts | Validate against DB values |
Info Disclosure | Log payment data | Don’t log tokens or sensitive payloads |
DoS | Infinite payment retry loop | Circuit breakers, exponential backoff |
Example: Databases: SQLi, leaked credentials
STRIDE Category | Threat | Explanation | Mitigation |
Spoofing | Attacker uses stolen DB credentials to impersonate a legitimate user | Unauthorized access using leaked DB credentials | Enforce strong authentication (e.g., IAM roles, multi-factor), rotate credentials regularly |
Tampering | SQL Injection alters database queries to manipulate data | Injection of malicious SQL to read/modify/delete data | Use parameterized queries/prepared statements, input validation, ORM usage |
Repudiation | Malicious DB users deny unauthorized changes | Lack of audit logs or tamper-proof logging | Enable detailed audit logging, immutable logs, monitoring suspicious DB activities |
Information Disclosure | Sensitive data leaked through injection or improper access | Unauthorized exposure of PII, credentials, business data | Encrypt sensitive data at rest and in transit, restrict query results, least privilege access |
Denial of Service | DB overwhelmed by heavy queries or injection causing crashes | Attackers degrade DB availability | Rate limit queries, use query timeout limits, monitor query performance, isolate DB resources |
Elevation of Privilege | Exploit injection or misconfiguration to gain higher DB privileges | Attackers escalate access to admin or system roles | Harden DB permissions, avoid running DB as superuser, apply patches and security updates |
Repeat for all major components:
Frontend: CSRF, script injection, session theft
Auth Service: Token spoofing, weak JWT signing
User Service: IDOR, insecure direct access
Order Service: Business logic flaws
Databases: SQLi, leaked credentials
Queues: Message spoofing, flooding
Secrets Store: Misconfigured access policies
CI/CD: Supply chain attacks, exposed secrets
Step 3: What Are We Doing About It? – Mitigations & Controls
We now map each threat to actionable security controls and tools:
Threat | Mitigation | Tool/Control |
JWT Replay Attack | Use short TTL, rotate signing keys | Auth0, Keycloak |
Sensitive Data Exposure | Mask PII in logs | ELK Stack, Datadog |
Broken Authentication | Enforce RBAC | OPA, Gatekeeper |
Secrets Leakage | Externalize secrets, audit access | HashiCorp Vault, IAM |
API Abuse | Rate limiting at gateway | Kong, AWS WAF, NGINX |
Integrate into DevSecOps pipeline:
SAST / DAST / SCA
IaC Scanning –
tfsec
,checkov
API Schema Validation – OpenAPI spec enforcement
Secrets Scanning –
truffleHog
,gitleaks
Step 4: Did We Do a Good Job?
Post-modeling, we evaluate and integrate:
Peer Review the threat model
Test Mapping – Turn threats into security test cases
Backlog Integration – Track in JIRA or GitHub Projects
Model Drift Detection – Update threat models over time
DevSecOps Integration: When & Where?
Dev Stage | Security Action |
Design | Threat model per feature |
Develop | Write abuse test cases |
Build | Enforce OPA/Kyverno policies |
Test | Pen-test high-risk components |
Deploy | CI/CD gate on threat model updates |
Operate | Monitor logs, alerts, anomalies |
Threat Modeling for APIs
1. Understand the API Architecture and Workflow
Identify:
API Gateway or Proxy
Clients (web, mobile, other services)
Backend microservices
Datastores (DB, cache)
Auth mechanisms (OAuth2, JWT, API keys)
External dependencies (3rd party APIs)
2. Identify Threats Using STRIDE
STRIDE | API-Specific Threats | Examples |
S | API key or JWT token theft | Impersonation |
T | Modify request payload | Malicious inputs |
R | Lack of traceability | No logs or tampered logs |
I | Sensitive data in responses | PII exposed in JSON |
D | Endpoint flooding | Bot attacks |
E | Privilege escalation | Access to admin routes |
3. Analyze API Threats
API Endpoint | Threat | Mitigation |
/login | Brute force | CAPTCHA, lockouts, rate limit |
/user/{id} | Info disclosure | AuthZ checks, data filtering |
/order POST | Tampering | Validate schema, logic checks |
4. Controls & Tools
Threat | Control | Tool |
JWT theft | Short TTL, rotate | Keycloak, Auth0 |
Input tampering | Schema validation | OpenAPI, JSON Schema |
Sensitive data | Masking, encryption | Vault, TLS, ELK |
DoS | Rate limiting | Kong, AWS WAF |
5. Integrate in DevSecOps
Design: Threat model per API
Develop: Use secure coding and schema enforcement
Build/Test: SAST/DAST/API tests
Deploy: Gate on test coverage, use secrets management
Operate: API observability and alerts
Sample Table: Threat Summary
Component | Threat | Risk | Control | Owner |
API Gateway | DoS | High | Rate limiting | DevOps |
Payment Service | Spoofed callbacks | High | Signature check | Backend |
Order Service | Broken auth | Critical | RBAC, JWT checks | Security |
Vault | Secrets exposure | Critical | IAM, Audit Logs | Platform |
Conclusion
Threat modeling isn't a one-time activity—it’s a continuous process. By integrating DFDs, STRIDE, and mitigations early in the DevSecOps pipeline, we can proactively identify, track, and mitigate threats in any modern microservices-based SaaS environment.
Subscribe to my newsletter
Read articles from Amit Sangwan directly inside your inbox. Subscribe to the newsletter, and don't miss out.
Written by

Amit Sangwan
Amit Sangwan
💼 Automation Engineer | AI Enthusiast | Tech Blogger Passionate about automation, AI agents, and testing. Exploring innovations in QA while sharing insights on technology and career growth. Always learning, always evolving. 🚀