Web Security / Basic: web trust and identity contracts / Lesson 2

Threat modeling and verifiable web requirements

Connect a feature’s assets and data flows to precise defensive requirements and evidence.

About 4 min readContent reviewed 2026-10-26

On this page

Lesson goals

Model actors, flows, assets, and changing trust assumptions.
Version requirements and distinguish a plan from a verified result.

Bound one real user task

Threat modeling starts with a service outcome and the harm that matters, not a list of dramatic attack names. For a fictional notes portal, distinguish reading public material, editing an assigned note, exporting private content, and recovering an account. Identify actors, stores, browser code, backend services, and external dependencies. Record who controls each part and where data or authority crosses a boundary. A component diagram without those decisions can look complete while omitting a support tool or exported copy. Keep assumptions explicit and involve people who understand development and operation.

Describe a plausible failure path and consequence

Ask how a boundary could allow disclosure, unauthorized change, unavailable service, or misuse of an otherwise legitimate operation. Include mistakes, stale permissions, and dependency failures as well as intentional misuse. A useful scenario names preconditions, existing controls, and uncertainty. Do not assume an internal network or trusted employee removes the need for resource-level permission. Prioritize by consequence, exposure, evidence, and recovery difficulty rather than treating every checkbox as equally important. The course uses benign fictional flows and does not perform discovery or testing against any target.

Write the boundary contract as inspectable data

The record below separates transport, authenticated context, export scope, and downstream retention. It is a local planning schema, not a vendor access policy or an ASVS identifier. A real implementation must connect each requirement to code, configuration, and operating evidence. Follow the exported copy after it leaves the primary application: recipient access, downloads, support handling, and deletion still matter. Mark unverified requirements honestly rather than labeling a diagram secure. A written requirement is valuable because it creates a clear question, not because writing it enforces the answer.

json A fictional export-flow requirement record

{
  "flow": "private-note-export",
  "boundary": "browser-to-export-service",
  "requirements": ["verified-session", "scoped-export-permission", "protected-transport", "owned-retention"],
  "ownerRole": "portal-maintainer",
  "evidenceState": "planned"
}

The file grants no permission and invokes no service. It names four separate requirements whose implementations still need review. The identifiers are local teaching labels rather than standard requirement numbers.

Map each important requirement to a bounded check

A requirement should state intended behavior, owner, verification method, and known limits. Include denied actions and failure handling rather than only successful users. OWASP ASVS 5.0.0 provides versioned verification requirements, while the Top 10 2025 is an awareness resource; neither is a universal automatic quality score. Record the selected version and mapping without inventing standard identifiers. The pure completeness check below finds a missing evidence reference in fictional records. A nonempty string would still need substantive review of result, scope, freshness, and artifact identity. Metadata completeness is not proof that a defense works.

python An offline requirement-evidence completeness check

requirements = [
    {"id": "LOCAL-EXPORT-SCOPE", "owner": "service-owner", "evidence": "scope-cases"},
    {"id": "LOCAL-EXPORT-RETENTION", "owner": "service-owner", "evidence": ""},
]
missing = [item["id"] for item in requirements if not item["owner"] or not item["evidence"]]
assert missing == ["LOCAL-EXPORT-RETENTION"]

Uses invented in-memory records only. The assertion identifies the retention gap. It does not inspect code, run a scanner, evaluate an ASVS control, or authorize a release.

Review the model when the feature changes

New identity recovery, a different file processor, a public sharing feature, or a supplier integration can change risk without altering the main database schema. Review affected flows, requirements, tests, logging, and recovery together. Record accepted exceptions with scope, owner, and expiry, and revisit assumptions after incidents or exercises. A completed document is not certification or evidence that all threats were considered. Keep the model small enough to maintain and precise enough to guide implementation. The result should help a reviewer explain what is protected, how, what was verified, and which uncertainty remains with an accountable owner.

Common errors and fixes

A diagram is called a verified defense

Why it happens: A planned control is confused with implementation evidence.
How to fix it: Attach scope, results, and limitations from appropriate checks.
Prevent it next time: Keep planned and verified states distinct.

The model stops at the encrypted connection

Why it happens: Identity, permission, and downstream copies were omitted.
How to fix it: Follow the complete data and authority path.
Prevent it next time: Review every meaningful trust crossing.

An unversioned requirement number changes meaning

Why it happens: A moving standard reference is treated as fixed.
How to fix it: Pin the selected standard version and review mappings.
Prevent it next time: Store version with the evidence record.

Check your understanding

1. A supplier begins processing private note exports. What should change in the model?

Show worked solution

Add the recipient, transfer, storage, identity, retention, failure, and recovery responsibilities. Determine which controls belong to the supplier and which the portal must verify. A stable application schema does not imply unchanged trust boundaries.

2. A requirement record contains a test filename. Is the scenario closed?