Origin API 在 Edge 145 中落地 — 原生 Origin 对象在浏览器中到来

ReactNode.jsDevOps

发生了什么

Microsoft Edge 145 推出了 Origin API — 一个原生的、结构化的 Origin 对象，允许网页代码解析、序列化和比较来源，而不再依赖脆弱的 ASCII 字符串。(learn.microsoft.com)

为什么这对全栈开发者很重要

更安全的来源比较：许多安全漏洞和逻辑错误来自比较序列化的来源字符串（或解析 location.origin），尤其是在不透明来源（沙盒 iframe、数据 URL 等）周围。Origin API 提供了浏览器的规范来源表示，并暴露了比较辅助函数，使您可以可靠地测试同源/同站关系，而无需脆弱的字符串处理。(learn.microsoft.com)
更少的边缘情况对于 iframe 和沙盒场景：不透明来源的行为是特殊的（仅与自身同源）。Origin API 让您可以直接推理这些语义，而不是发明自定义字符串启发式。(learn.microsoft.com)
更简单的服务器/客户端协调：当前从头部、查询参数或 document.referrer 解析来源的服务器逻辑可以简化（或至少可以验证）与浏览器使用的相同规范表示，从而减少导致身份验证/会话问题和 CSRF/CORS 错误的不匹配。(learn.microsoft.com)

简短总结

浏览器提供了一个一流的 Origin 对象，支持解析/序列化和稳健的来源/站点比较；浏览器已将该功能移入稳定通道，并在 HTML 规范/测试中反映该功能。(learn.microsoft.com)

立即检查清单 — 团队的实用步骤（高优先级）

审计来源比较和身份验证检查（1–2 天）
- 在代码库中搜索任何使用字符串相等性比较来源的逻辑（例如，a.origin === b.origin，正则解析主机名，手动子字符串检查）。将这些地方视为风险点，并添加测试或功能标志以进行现代化。
功能检测和渐进增强（几分钟）
- 使用功能检测（if (typeof Origin !== 'undefined')）在可用时使用原生 API，并为旧浏览器保留当前的回退。
- 示例模式（概念性，内联）：
  - 如果 Origin 存在：const o = Origin.from(someValue); o.isSameOrigin(otherOrigin);
  - 否则：继续使用经过良好测试的、集中化的回退辅助函数，封装您的基于字符串的逻辑。
更新服务器端验证和日志记录（几小时）
- 在服务器验证来源头（CORS、令牌绑定、Webhook 验证）时，记录接收到的序列化来源和在推出期间由客户端代码生成的规范来源。这将提前暴露不匹配。
在集成测试中加强 iframe / 沙盒行为（1–3 天）
- 为沙盒 iframe、数据/文件 URL 和重定向添加集成测试，以验证会话和 SameSite 处理。Origin API 使许多边缘情况变得明确；对其进行测试。
规划替换路线图（2–4 个冲刺）
- 重构关键安全路径（CSRF 检查、会话绑定、支付流程），在可行的情况下优先考虑规范的 Origin 比较。从低风险服务开始，逐步推进。

兼容性和推出说明

Origin API 正在 Chromium 基础的稳定通道中落地（Edge 145 / Chromium 船运活动），相关的引擎工作也出现在其他浏览器引擎中；推出因浏览器和平台而异 — 在过渡期间继续使用功能检测并维护回退。(learn.microsoft.com)
不要假设普遍可用 — 将 API 视为渐进增强，并在您测量到客户端采用之前，用服务器端验证保护关键流程。

风险和注意事项

结论

Origin API 是一个微妙的、高杠杆的网络平台改进：它减少了历史上导致安全和会话管理问题的来源/解析错误类别。首先审计来源比较，添加功能检测，并在采用达到您的用户基础后，逐步迁移关键检查以使用规范比较。(learn.microsoft.com)

来源：

继续阅读