前端安全实践：用 Sandbox Iframe 隔离敏感输入
电商 Checkout 场景下，如何通过 sandbox iframe + 中间层转发，以最小改动将地址和证件等敏感输入从主页面隔离。
背景：合规压力下的"最小改动"难题
电商 checkout 页面天然要处理大量敏感信息——用户地址、证件号、税号……这些数据要么在页面里展示，要么需要用户填写。
更要命的是，这几年 AI 工具的普及让攻击门槛大幅降低。以前还需要点技术功底的 XSS 注入、中间人攻击，现在大模型可以直接帮黑客生成攻击脚本、自动化扫描漏洞、甚至模拟正常用户行为绕过风控。安全审计的要求越来越严格：敏感输入过程不应该出现在主页面中。
但现实是，checkout 地址模块经过多年迭代，逻辑深、耦合多，直接推倒重写不现实。
所以我们的问题变成了：怎么在不重构现有主链路的前提下，把敏感输入隔离出去？
方案选型：为什么不选"全量重写"
讨论阶段我们列了几个方向：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 全页面重构 | 彻底干净 | 工期长，回归风险高 |
| 前端加密 | 改动小 | 密钥管理是新的安全隐患 |
| Token 化 | 最安全 | 需要改后端数据模型和所有消费方 |
| sandbox iframe + 中间层 | 改动最小，隔离有效 | 首屏仍暴露只读数据 |
我们选了最后一种。核心判断是：一期先把"输入过程"隔离掉，已经能解决最大的安全痛点。首屏的只读展示可以后续再处理。
架构思路：三层各司其职
整个方案分三层，职责边界很清晰：
1. 父页面（Checkout 主页面）
- 继续负责地址列表查询和展示（一期不改这条链路）
- 新增/编辑按钮改为打开 iframe 弹窗
- 为每次操作申请短期会话凭证
- 监听 iframe 的保存成功消息，然后刷新地址列表
父页面不做的事情：不渲染敏感表单、不读 iframe DOM、不监听用户输入过程。
2. 收集器（Sandbox Iframe）
- 独立渲染完整的地址/证件表单
- 自行维护表单状态和校验
- 通过会话凭证从中间层获取初始化数据（国家列表、编辑回填值等）
- 提交也走中间层，不直连后端业务接口
- 保存成功后通过
postMessage通知父页面
关键设计：同一个收集器通过 scope 参数支持两种模式——完整地址表单和仅证件表单，避免维护两套页面。
3. 中间层（Node Facade）
这是整个方案的"收口"点：
- 管理短期会话凭证（30 分钟有效，提交成功后立即失效）
- 聚合国家列表和编辑回填数据，返回给 iframe
- 转发地址保存和证件保存请求到真实后端
- 统一做日志脱敏和参数过滤
中间层不存储地址明文，不做长期草稿，也不替代现有地址列表主数据源。
会话管理：安全性和用户体验的平衡
会话凭证的设计是安全性的核心：
- 短期有效：固定 30 分钟过期，提交成功后立即失效
- 用户绑定：凭证绑定当前登录用户、站点和操作模式
- 单会话约束：同一页面同时只允许一个有效会话，新建会话自动让旧会话失效
- 编辑权限校验：编辑模式时，会验证当前用户是否有权编辑该地址
这样即使凭证泄露，攻击窗口也很小，且无法跨用户使用。
提交策略：多接口联动的失败处理
实际保存时需要调用多个后端接口（地址主体、证件号、默认地址设置等），失败处理策略必须提前想清楚：
执行顺序： 先保存地址主体 → 再保存证件信息 → 最后处理默认地址和账单地址同步
失败场景：
- 地址保存成功、证件保存失败：不做补偿删除（新增场景下），返回"部分保存"状态，提示用户确认
- 地址和证件都成功、但默认地址同步失败：同样返回"部分保存"状态
- 编辑场景下部分失败：不承诺自动回滚，提示用户重试或手动刷新
核心原则：宁可知疑地告诉用户"请确认"，也不要假装成功了。
消息校验：不让 postMessage 成为新的攻击面
父页面和 iframe 通过 postMessage 通信，这本身也可能被利用。我们的防护措施：
- 校验消息来源是否为 iframe 的
contentWindow - 每次会话生成随机 nonce，iframe 回传时必须携带
- 只处理白名单消息类型（如保存成功），忽略其他所有消息
- 不把
event.origin作为唯一信任依据
做不到的事情（诚实面对）
一期方案有明确的边界：
- ❌ 首屏地址列表仍然在父页面中展示完整地址
- ❌ 中间层和后端在保存/回填时仍然能看到完整地址
- ❌ 不做删除地址、设置默认地址的前端重构
这些不是"忘了做"，而是刻意的取舍。一期目标是输入过程隔离，不是全链路数据脱敏。
灰度策略：从单站点开始
一期通过 feature flag 控制，首批只在一个站点（巴西）上线。观测的核心指标：
- 会话过期率
- 移动端收集器打开成功率
- 新增/编辑保存成功率
- 部分保存错误率
稳定后再逐步扩展到其他站点。
总结
回头看这个方案，最大的体会是：安全改造不一定要"大拆大建"。
找到一个足够小的切口，先把最大的风险点解决掉，然后逐步扩展。比起憋一个"完美方案"然后迟迟上不了线，这种渐进式的方法反而更务实。
当然，sandbox iframe 不是银弹。如果未来要做到全链路脱敏（包括首屏展示），就需要更底层的数据模型改造。但那是下一步的事了。
先把眼前的问题解决，再谈理想。