Threat Modeling a Web Application

Set scope and authorization

Define the application version, environments, user groups, integrations, and business processes included in the review. Record the system owner and written authorization for any active testing. Production probing is not the default. Use diagrams, configuration review, code review, and an isolated test environment whenever they answer the question with less risk.

State what is outside scope, including third-party services that the team does not own. Name the escalation contact for an exposed secret, active compromise, or unexpected customer-data access. Confirm backups and recovery ownership before testing a control that could affect availability or stored information.

Map assets and trust boundaries

List data and actions that matter: account recovery, administrative changes, payment state, private files, audit records, and deployment credentials. Draw the browser, application, identity provider, database, queues, storage, and external APIs. Mark every place where data crosses between users, services, networks, or privilege levels.

For each flow, record authentication, authorization, validation, encryption, retention, and logging controls. Do not assume an internal service is trusted merely because it has no public address. Service identities, build systems, support tools, and background jobs often cross meaningful boundaries and should receive least-privilege access.

Develop defensive misuse cases

Ask how a normal feature could expose data, accept the wrong authority, lose integrity, or become unavailable. Phrase scenarios as control questions, such as whether one tenant can reference another tenant's object or whether a support role can export more data than needed. Avoid payloads and operational attack recipes.

Include accidents and dependency failures, not only hostile behavior. A stale authorization cache, overly broad storage policy, leaked deployment token, or missing deletion job can create serious exposure. Connect each scenario to an asset, boundary, existing control, evidence source, and safe validation method.

Prioritize controls and follow-up

Estimate consequence using confidentiality, integrity, availability, privacy, safety, and recovery cost. Consider how reachable the condition is and what controls already reduce it. Use the organization's risk method consistently, but do not claim a score guarantees safety. Record uncertainty and seek specialist review for high-impact unknowns.

Prefer design changes such as server-side authorization, segmented identities, secure defaults, and minimized data over warnings alone. Assign an owner, target date, verification method, and fallback for every accepted treatment. Revisit the model after architecture changes, incidents, major dependency updates, and at least quarterly.

Model a team document-sharing feature

An authorized product team plans links that let signed-in members share documents with colleagues inside the same organization.

1. Diagram browser, API, identity service, document database, object storage, and audit log, then mark tenant and service boundaries.
2. List document content, sharing permissions, link state, and audit evidence as protected assets with named owners.
3. Ask whether server-side checks enforce tenant, membership, document, and action on every read and update path.
4. Review code and automated tests in an isolated environment using synthetic organizations, including revoked membership and expired links.
5. Assign changes for deny-by-default policy, scoped storage access, useful logging, backups, and an incident escalation route.

Threat-model review playbook

Use this record for a bounded, repeatable review of an application change.

• Scope: owner, authorization, environment, release, included components, exclusions, and escalation contact.
• System map: assets, actors, data flows, trust boundaries, service identities, and external dependencies.
• Scenario register: affected asset, failed assumption, existing safeguard, evidence, and safe test method.
• Treatment plan: preventive control, detection, backup or recovery step, owner, due date, and residual risk.
• Review trigger: architecture change, material incident, new integration, privilege change, or quarterly check.

Common mistakes

• Starting with a threat catalog before agreeing on the application's assets, boundaries, and authorized scope.
• Testing a third-party or production system without explicit permission, isolation, backups, and an escalation plan.
• Recording risks without owners, verification evidence, recovery controls, or a date for reassessment.

Try one

Sources

• OWASP Threat Modeling Cheat SheetOWASP guidance for structured application threat modeling.
• CISA Secure by DesignCISA guidance for making customer security a core product requirement.