Threat Modeling for Modern SaaS Platforms
Micro services-based API architecture
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
pytmfor 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,checkovAPI Schema Validation – OpenAPI spec enforcement
Secrets Scanning –
truffleHog,gitleaks,ggshield
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.
Reference Document: https://owasp.org/www-community/Threat_Modeling_Process#step-1-scope-your-work
