Threat Modeling for Modern SaaS Platforms

Amit SangwanAmit Sangwan
7 min read

Let’s imagine we’re building a SaaS web application with the following components:

ComponentTechnology StackResponsibility
FrontendReact / Next.jsUI for users to interact with the app
API GatewayNGINX or AWS API GatewayEntry point, routing, security
Auth ServiceOAuth2, JWTAuthentication and token issuance
User ServiceNode.js / Python / GoHandles user profile management
Order ServiceNode.js / Python / GoHandles customer orders
Payment ServiceStripe APIIntegrates with external payment systems
DatabasesPostgreSQL (Users), MongoDB (Orders)Data persistence per service
QueueRabbitMQ or KafkaAsynchronous order processing
MonitoringPrometheus, Grafana, ELKObservability and log management
Secrets StoreHashiCorp Vault / AWS Secrets ManagerSecure secrets and key storage
CI/CDGitHub Actions + KubernetesAutomation 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

  1. User → API Gateway (Login, Place Order)

  2. API Gateway → Auth Service (Token Verification)

  3. API Gateway → User Service (User Profile)

  4. API Gateway → Order Service (Order Creation)

  5. Order Service → Payment Provider (Charge via Stripe)

  6. Order Service → Message Queue (Emit Order Event)

  7. Services ↔ Databases

  8. 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 CategoryThreatMitigation
SpoofingAttacker impersonates serviceMutual TLS, JWT validation
TamperingAPI parameters modified in transitEnforce HTTPS, input validation
RepudiationLogs are missingCentralized logging with signed logs
Information DisclosureSensitive data in error responsesData classification, limit over-fetching
DoSFlood API with requestsWAF, rate limiting, caching
EoPMissing auth header allows escalationEnforce OAuth2, strict AuthN at gateway

Example: Payment Service

STRIDE CategoryThreatMitigation
SpoofingFaked payment callbacksValidate Stripe signatures
TamperingModify order amountsValidate against DB values
Info DisclosureLog payment dataDon’t log tokens or sensitive payloads
DoSInfinite payment retry loopCircuit breakers, exponential backoff

Example: Databases: SQLi, leaked credentials

STRIDE CategoryThreatExplanationMitigation
SpoofingAttacker uses stolen DB credentials to impersonate a legitimate userUnauthorized access using leaked DB credentialsEnforce strong authentication (e.g., IAM roles, multi-factor), rotate credentials regularly
TamperingSQL Injection alters database queries to manipulate dataInjection of malicious SQL to read/modify/delete dataUse parameterized queries/prepared statements, input validation, ORM usage
RepudiationMalicious DB users deny unauthorized changesLack of audit logs or tamper-proof loggingEnable detailed audit logging, immutable logs, monitoring suspicious DB activities
Information DisclosureSensitive data leaked through injection or improper accessUnauthorized exposure of PII, credentials, business dataEncrypt sensitive data at rest and in transit, restrict query results, least privilege access
Denial of ServiceDB overwhelmed by heavy queries or injection causing crashesAttackers degrade DB availabilityRate limit queries, use query timeout limits, monitor query performance, isolate DB resources
Elevation of PrivilegeExploit injection or misconfiguration to gain higher DB privilegesAttackers escalate access to admin or system rolesHarden 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:

ThreatMitigationTool/Control
JWT Replay AttackUse short TTL, rotate signing keysAuth0, Keycloak
Sensitive Data ExposureMask PII in logsELK Stack, Datadog
Broken AuthenticationEnforce RBACOPA, Gatekeeper
Secrets LeakageExternalize secrets, audit accessHashiCorp Vault, IAM
API AbuseRate limiting at gatewayKong, AWS WAF, NGINX

Integrate into DevSecOps pipeline:

  • SAST / DAST / SCA

  • IaC Scanningtfsec, checkov

  • API Schema Validation – OpenAPI spec enforcement

  • Secrets ScanningtruffleHog, 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 StageSecurity Action
DesignThreat model per feature
DevelopWrite abuse test cases
BuildEnforce OPA/Kyverno policies
TestPen-test high-risk components
DeployCI/CD gate on threat model updates
OperateMonitor 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

STRIDEAPI-Specific ThreatsExamples
SAPI key or JWT token theftImpersonation
TModify request payloadMalicious inputs
RLack of traceabilityNo logs or tampered logs
ISensitive data in responsesPII exposed in JSON
DEndpoint floodingBot attacks
EPrivilege escalationAccess to admin routes

3. Analyze API Threats

API EndpointThreatMitigation
/loginBrute forceCAPTCHA, lockouts, rate limit
/user/{id}Info disclosureAuthZ checks, data filtering
/order POSTTamperingValidate schema, logic checks

4. Controls & Tools

ThreatControlTool
JWT theftShort TTL, rotateKeycloak, Auth0
Input tamperingSchema validationOpenAPI, JSON Schema
Sensitive dataMasking, encryptionVault, TLS, ELK
DoSRate limitingKong, 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

ComponentThreatRiskControlOwner
API GatewayDoSHighRate limitingDevOps
Payment ServiceSpoofed callbacksHighSignature checkBackend
Order ServiceBroken authCriticalRBAC, JWT checksSecurity
VaultSecrets exposureCriticalIAM, Audit LogsPlatform

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.


0
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. 🚀