Threat Modeling Before Writing Code

The cheapest security defect to fix is the one found while the architecture is still a diagram. Threat modeling makes security decisions explicit before they become expensive code, migrations, or production incidents.

Keep the first model small

You do not need a heavyweight workshop. Start with one feature or user journey: sign-in, file upload, booking, payment, password recovery, or an administrative action. Record the actors, data, components, external services, entry points, and assumptions involved.

1. Draw the data flow

Show the browser or mobile app, API, database, queues, object storage, administrators, and third-party services. Add arrows for data movement. Mark every point where data crosses from one level of trust to another-for example, from a public client into an API or from your backend into an external service.

2. Ask what can go wrong

Use concrete abuse cases rather than vague labels. Could one tenant access another tenant's records? Could an attacker replay a reset link, upload an executable file, enumerate accounts, exhaust an expensive endpoint, forge a webhook, or use an administrator function through a regular account?

3. Rank by product impact

Combine likelihood with impact, but keep the reasoning visible. Exposure of public profile text is not equivalent to exposure of authentication tokens or private customer records. Prioritization should reflect the data, users, business process, and recovery cost of this specific product.

4. Convert risks into engineering work

A useful mitigation is testable. “Improve security” is not a task; “verify tenant ownership on every property query” is. Assign an owner and define the control: authorization policy, data minimization, encryption, rate limiting, audit logging, isolation, validation, or a safer architecture.

5. Add verification before closing the risk

Each accepted mitigation should produce evidence. That might be a unit test for a policy, an integration test using a second tenant, a negative API test, a configuration check, or a manual review of a signed mobile build. A control without verification remains an assumption.

A reusable four-question review

What are we building? Define scope, assets, actors, flows, and trust boundaries.
What can go wrong? Identify realistic misuse and failure scenarios.
What will we do? Avoid, reduce, transfer, or consciously accept each risk.
Did it work? Test the mitigation and update the model when the system changes.

When to revisit the model

Review it when adding a new integration, privileged role, sensitive data type, public endpoint, tenant boundary, deployment environment, or authentication flow. Threat models are living design artifacts, not documents created once for compliance.

Reference

The OWASP Threat Modeling Cheat Sheet provides a methodology-neutral starting point and practical prompts for modeling, identifying threats, choosing responses, and validating the result.