SaaS Security: Threat Modeling Strategies

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,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

The Deployment Architecture of an Enterprise API Management Platform.. - Vamsi Talks Tech

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

Threat Modeling for Modern SaaS Platforms