security · advanced
Threat Modelling for Backend Services
Quick answer
Threat modelling is a structured design activity: identify assets, trust boundaries, actors, and threats, then prioritize mitigations. Staff engineers run light threat models on high-risk changes (auth, payments, multi-tenant data) so security is a design input—not a release-week surprise. This article is educational; it is not a penetration-test substitute or legal advice.
Why this matters
- Most severe bugs are design flaws, not typos.
- Payments and identity concentrate attacker value.
- Architecture reviews without threats miss abuse cases.
- Regulated domains expect evidence of thinking, not slogans.
Learning objectives
- Draw a simple data-flow diagram with trust boundaries.
- Apply a practical STRIDE-style checklist.
- Prioritize threats by impact and likelihood.
- Turn threats into controls and tests.
- Know when to escalate to specialists.
Explain like I am 5
Before leaving a toy outside, ask: who might take it, how, and what lock or light would help?
Mental model
flowchart LR
Actor --> Boundary[Trust boundary]
Boundary --> Asset
Asset --> Threat
Threat --> Mitigation
| STRIDE-ish class | Backend example |
|---|---|
| Spoofing | Stolen API token |
| Tampering | Modified webhook payload |
| Repudiation | Missing audit log for refunds |
| Information disclosure | IDOR on account objects |
| Denial of service | Unbounded fan-out / expensive query |
| Elevation of privilege | Confused deputy between services |
Core concepts
Assets and abusers
List what matters (PII, money movement, secrets, admin actions) and who might attack (external, insider, compromised dependency).
Trust boundaries
Where data crosses identity or network control: browser→API, service→service, third-party webhooks, batch jobs. Threats cluster at boundaries.
Data-flow diagrams (lightweight)
Boxes and arrows beat 50-page models. Update when the design changes.
Prioritization
Not every threat is equal. Rank by blast radius (money, privacy, integrity) and ease of exploit. Fix top risks first.
Mitigations as design
Authn/z, least privilege, encryption, validation, rate limits, audit logs, isolation, kill switches. Record residual risk explicitly.
Cadence
Run on new services, major RFCs, and after relevant incidents—not only annually for theater.
Worked example
System: Payment refund API.
Assets: refund capability, account balances, customer PII.
Boundaries: partner webhook, internal admin UI, service-to-ledger calls.
Top threats: spoofed webhook; IDOR refund of another account; replay; admin privilege abuse.
Mitigations: signed webhooks + timestamp; authZ on account ownership; idempotency keys; dual control for large refunds; audit trail.
Residual risk: insider with dual-control collusion—accepted with monitoring.
Trade-offs
| Deep annual model | No model |
|---|---|
| Stale docs | Surprise breaches |
| Good for compliance theater if unused | Fast shipping, higher risk |
Staff default: short, frequent models on high-risk change.
Failure modes
| Mode | Mitigation |
|---|---|
| Checklist cosplay | Tie threats to real data flows |
| Only external attackers | Include insiders and supply chain |
| No follow-up | Tickets + tests for top threats |
| Security as veto only | Co-design mitigations with product |
| DIY crypto | Prefer platform standards |
Interview mode
Skeleton: “I threat-model at trust boundaries—assets, STRIDE-style threats, prioritized mitigations, residual risk—especially for identity and money paths.”
Knowledge check
Trust boundaries where data or control crosses systems
Only inside pure in-memory CPU loops with no I/O
Only after ignoring authentication completely forever
Only in CSS styling
Human review
Security-sensitive topic: validate controls against your org’s standards, threat intel, and legal requirements before production claims.
Related
By Shubham Jain