Prompt and scope
Review an architecture where a browser accesses a multi-tenant web application. How would you draw boundaries and data flows, identify assets and threat sources, distinguish target, implementation, and external threats, and turn responses into verifiable security invariants?
The W3C Security Interest Group published the Threat Model for the Web Group Note Draft on 26 May 2026. It is informative and non-normative, intended to support security reviews of new Web specifications. Its simplified view includes a browser, DNS, a Web Server, users, and network operators. The interview tests the method and evidence chain, not memorization of the draft.
What the interviewer evaluates
The interviewer wants to see a system and data-flow picture before a vulnerability list; explicit assets, stakeholders, and threat sources; a distinction among threats, vulnerabilities, impacts, and responses; and security goals expressed as checkable invariants. Explain how the model evolves and feeds design and review documents. A strong answer states abstraction boundaries, attacker assumptions that are not modeled, and how out-of-scope dependencies are handed off.
Clarifying questions before answering
- Are we reviewing the browser platform, one web application, or a new Web API between them?
- Are credentials, user data, code, sessions, network metadata, and availability all in scope?
- Do flows include third-party scripts, CDNs, DNS, identity providers, and cross-site requests?
- Is this an architecture review, a pre-release security review, or an operational change review?
- Which dependencies and external threats are explicitly out of scope, and who owns the follow-up?
A 30-second answer framework
“I start with a data-flow diagram with unique IDs for components, stores, flows, and stakeholders. I enumerate assets and threat sources, then record prerequisites, affected flows, impact, existing controls, and residual risk for each threat. I classify it as a target threat, implementation threat, or external dependency. Each response becomes a security invariant with test or audit evidence, an owner, and an update trigger. The model starts with use cases and evolves with the design so a version is ready before formal security review.”
Step-by-step deep dive
1. Draw the system boundary first
Start with a minimal usable scenario: browser process and storage, DNS service, Web Server, user, site administrator, and network operator. Give every component a short unique ID and a prose dictionary describing its responsibility and trust boundary. If reviewing a new API, place its inputs, outputs, permissions, and dependencies in this picture instead of creating an isolated diagram.
2. Enumerate assets and stakeholders
Assets may include credentials, session tokens, user content, scripts, source identity, DNS results, availability, and privacy metadata. Stakeholders include end users, site operators, network operators, application providers, and public officials. Separate who is affected from who might attack; treating users only as assets hides important safety decisions.
3. Record threat sources and high-level threats
For each threat, state its source, target asset, attack path, and impact. Spoofing, tampering, disclosure, denial of service, and authorization bypass can organize the list, but every entry must map back to a concrete flow. Classify threats as target threats addressed by the specification, implementation threats known to implementers but unsuitable for normative constraints, or external threats from dependencies and deployment.
4. Turn responses into invariants
A security invariant is a condition that should hold for every permitted execution, such as “a cross-origin response never gives an unauthorized caller a credential” or “a redirect cannot bypass script-origin and permission boundaries.” Bind each invariant to a control and test, log, or audit evidence. Mark whether it is a specification guarantee, implementation guarantee, or deployment assumption.
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. Handle dependencies and external threats
The Web depends on DNS, TLS, HTTP, certificates, routing, scripts, and other layers. Do not pretend one model covers every dependency. List inherited assumptions and hand-off points. DNS spoofing, resource tampering, or network surveillance may be outside the current specification, but cite the related technology’s threat model and record the assumption you rely on.
6. Keep the model aligned with the lifecycle
Start the threat model with use cases, explainers, and the first design draft, then update it as features and flows change. Triggers include new entry points, permission changes, new dependencies, browser-process boundary changes, and real incidents. Version the model, review notes, and diffs so teams can tell whether a risk was added, closed, or reclassified. A completed version should exist before formal horizontal security review.
7. Prove that responses work
Use unit and integration tests, browser security tests, attack simulation, configuration checks, and log queries. For an invariant that cannot be tested directly, provide an auditable rationale, residual risk, and accepting owner. “No vulnerability found” is not proof; state observation scope, test conditions, and uncovered areas.
High-quality sample answer
I would define a minimal browser-access scenario with unique IDs for the browser process and storage, DNS, Web Server, user, and network operator, and provide a dictionary for every flow. I would enumerate credentials, sessions, user content, scripts, resolution results, and privacy metadata as assets. Each threat would include source, prerequisites, affected flow, and impact, then be classified as a target, implementation, or external dependency threat. Every response would become a checkable invariant tied to controls, tests, logs, or audit evidence and an owner. The model would begin with use cases and the first design draft, update when entry points, dependencies, or permissions change, and be versioned before security review. For DNS, TLS, scripts, and routing I would cite related models and make residual risks explicit. This makes the review useful for both implementation and future changes.
Common mistakes
- Listing vulnerability names only → there is no boundary or flow → draw components, flows, and trust boundaries first.
- Mixing threats, vulnerabilities, and impacts → responses cannot be verified → record source, prerequisites, impact, and controls separately.
- Putting every risk in the current specification → scope becomes false → classify target, implementation, and external threats.
- Creating one model just before release → design changes are missed → start with use cases and define update triggers.
- Writing security goals as slogans → no acceptance evidence exists → rewrite them as invariants tied to tests, logs, or audits.
- Ignoring residual risk → decisions cannot be traced → state uncovered areas, accepting owners, and follow-up actions.
Follow-up questions and responses
Why not enumerate every attacker first?
Defining components, assets, and flows first prevents scope drift. An attacker model can be added, but guesses about motives cannot replace analysis of boundaries and verifiable controls.
How do you handle third-party scripts?
Put the script source, loading flow, accessible credentials, and execution permissions in the model. Define source restrictions, isolation, and monitoring invariants; if a vendor owns a control, record the hand-off evidence and residual risk.
When does an external dependency become a project risk?
When its security assumption directly affects an in-scope asset or invariant, or the project cannot verify the dependency’s promise, record it as a current risk with a mitigation or accepting owner rather than a footnote.
What if the security review model is too complex?
Keep a minimal diagram covering the major risks, split protocol or deployment detail into linked submodels, and preserve traceability with component and flow IDs. Do not reduce complexity by deleting a critical boundary.
How do you explain residual risk to a product owner?
Describe affected assets, plausible paths, current controls, test evidence, and business impact. Offer options with cost, deadline, and an explicit accepting owner; avoid “absolutely secure” or unsupported probability claims.