题干与适用场景
请评审一个浏览器访问多租户 Web 应用的架构。你如何画出系统边界和数据流，识别资产与威胁来源，区分目标、实现和外部威胁，并把响应写成可验证的安全不变量？
W3C Security Interest Group 于 2026 年 5 月 26 日发布了 Threat Model for the Web Group Note Draft。该草案是信息性、非规范性文件，用于新 Web 规范的安全评审，并以浏览器、DNS、Web Server、用户和网络运营者等简化组件说明威胁模型。面试重点是方法和证据链，不是背诵草案结论。
面试官考察点
面试官会看你能否先画出系统和数据流，再讨论资产、利益相关者和威胁来源；能否区分威胁、漏洞、影响和响应；能否把安全目标写成可检查的不变量；能否持续更新模型并把结论放入设计和评审文档。优秀回答还会说明模型的抽象边界、未建模攻击者假设，以及如何处理规范外的依赖风险。
回答前需要澄清的问题
- 评审对象是浏览器平台、某个 Web 应用，还是两者之间的新 Web API？
- 要保护的资产包括凭据、用户数据、代码、会话、网络元数据还是可用性？
- 数据流是否包含第三方脚本、CDN、DNS、身份提供商和跨站请求？
- 威胁模型用于设计初审、发布前安全审查，还是线上变更评估？
- 哪些依赖和外部威胁明确在范围外，谁负责接续评审？
30 秒回答框架
“我先用一张带唯一 ID 的数据流图定义边界，列出组件、存储、流和利益相关者，再逐项列资产与威胁来源。对每个威胁记录前置条件、受影响流、影响、已有控制和残余风险，并把它归类为规范目标、实现风险或外部依赖。然后将响应写成安全不变量和验证证据，分配负责人和更新触发器。模型应与系统设计同步开始，在正式安全评审前形成可审计版本。”
分步骤深入解答
1. 先画清系统边界
从最小可用场景开始，标出浏览器进程与存储、DNS 服务、Web Server、用户、站点管理员和网络运营者。每个组件使用唯一短 ID，并配套文字字典解释职责和信任边界。若评审的是新 API，再把 API 的输入、输出、权限和依赖嵌入这张图，而不是另画一张孤立图。
2. 列出资产与利益相关者
资产可以是凭据、会话令牌、用户内容、脚本、来源身份、DNS 解析结果、可用性和隐私元数据。利益相关者包括终端用户、网站运营者、网络运营者、应用提供方和公共部门。把“谁受影响”与“谁可能攻击”分开，避免只把用户当成需要保护的对象。
3. 记录威胁来源和高层威胁
对每项威胁说明来源、目标资产、攻击路径和影响。可以用仿冒、篡改、信息泄露、拒绝服务、权限绕过等类别组织清单，但必须回到具体数据流。将威胁分成规范希望处理的目标威胁、实现者已知但不适合写入规范约束的实现威胁，以及依赖或部署环境造成的外部威胁。
4. 把响应写成不变量
安全不变量是系统在所有允许执行中都应保持的条件，例如“跨来源响应不会把未授权凭据交给调用方”“脚本来源和权限边界不能被响应重定向绕过”。每条不变量关联控制、测试、日志或审计证据，并注明是规范保证、实现保证还是部署前提。
component/flow -> asset -> threat source -> impact
-> invariant -> control -> evidence -> owner5. 处理依赖和外部威胁
Web 依赖 DNS、TLS、HTTP、证书、路由和脚本等多层协议。模型不应假装覆盖所有依赖，而要列出依赖威胁、继承的安全假设和交接点。例如 DNS 欺骗、资源篡改或网络监视可能超出当前规范范围，但必须引用相关技术的威胁模型，并记录采用的前提。
6. 让模型与生命周期同步
威胁模型应在用例、解释文档和设计初稿阶段开始，随着功能和数据流变化持续更新；正式横向安全评审前应准备完成。变更触发器包括新增入口、权限变化、新依赖、浏览器进程边界变化和现实事件。版本化模型、评审记录和差异说明，才能知道风险是新增、关闭还是被重新分类。
7. 证明响应有效
设计评审阶段可用单元测试、集成测试、浏览器安全测试、攻击模拟、配置检查和日志查询验证响应。对无法测试的不变量，给出可审查的理由、残余风险和接受者。不要把“没有发现漏洞”写成证明；要说明观察范围、测试条件和未覆盖区域。
高质量示范回答
我会先定义一个最小浏览器访问场景，用唯一 ID 标出浏览器进程及其存储、DNS、Web Server、用户和网络运营者，并为每条数据流写字典。接着列出凭据、会话、用户内容、脚本、解析结果和隐私元数据等资产，再记录每个威胁的来源、前置条件、受影响流和影响。威胁清单区分规范目标、实现风险和外部依赖，避免把部署前提伪装成规范保证。每个响应都写成可检查的不变量，绑定控制、测试或审计证据和负责人。模型从用例和设计初稿开始，新增入口、依赖或权限变化时更新，正式安全评审前冻结一个带版本的模型。对 DNS、TLS、脚本和路由等外部依赖，我会明确引用其模型或安全假设，并保留残余风险。这样评审结果既能指导设计，也能在后续变更中复用和追踪。
常见错误
- 只列漏洞名称 → 没有系统边界和数据流 → 先画组件、流和信任边界。
- 把威胁、漏洞和影响混为一谈 → 响应无法验证 → 逐项记录来源、前置条件、影响和控制。
- 把所有风险都塞进当前规范 → 范围失真 → 区分目标、实现和外部威胁并标注依赖。
- 只在发布前做一次模型 → 设计变化未被覆盖 → 从用例阶段开始并设置更新触发器。
- 把安全目标写成口号 → 没有验收证据 → 改写为不变量并绑定测试、日志或审计。
- 忽略残余风险 → 决策不可追踪 → 写明未覆盖区域、接受者和后续行动。
追问及应对
为什么不先枚举所有攻击者？
先定义组件、资产和数据流可减少范围漂移。攻击者模型仍可补充，但不能让对攻击者动机的猜测替代对系统边界和可验证控制的分析。
如何处理第三方脚本？
把脚本来源、加载流、可访问凭据和执行权限画入模型，定义来源约束、隔离和监控不变量；若由供应商负责，记录交接证据和残余风险。
什么时候把外部依赖升级为当前项目风险？
当依赖的安全假设直接影响当前资产或不变量，或项目无法验证依赖承诺时，就应列为当前风险并指定缓解或接受者，而不是留在脚注。
安全评审发现模型过于复杂怎么办？
保留覆盖主要风险的最小图，拆出协议或部署层的子模型，并通过组件 ID、流 ID 和链接保持可追溯；复杂度不能通过删除关键边界来降低。
如何向产品负责人解释残余风险？
用受影响资产、可能路径、当前控制、测试证据和业务影响说明，给出选项、成本、期限和明确接受者，不用“绝对安全”或不可验证的概率承诺。