开发者不理解 CORS（2019）

原文 ↗ Hacker News 讨论 ↗

总体情绪

  • 许多参与者承认自己其实并不真正理解 CORS，即使是经验丰富的 Web 开发者也是如此。
  • 评论线程本身也被引用为证据，说明整个生态对 CORS 及其威胁模型都存在深度困惑。

同源策略 vs CORS

  • 多条评论强调，核心安全机制是同源策略（Same-Origin Policy，SOP）；CORS 是一种有选择地放宽它的方式。
  • 关键澄清：浏览器通常会阻止跨源响应的读取，而不是阻止请求的发送；CORS 允许服务器选择性地放行某些跨源读取。

威胁模型以及 CORS 实际保护什么

  • CORS 被描述为保护“浏览器中的用户”免受恶意第三方网站攻击，而不是保护后端免受普通 HTTP 客户端的访问。
  • 典型场景：用户登录了站点 A（已设置 cookie），然后访问恶意站点 B，B 试图读取 A 的私有数据或冒用用户在 A 上执行操作。
  • 多条评论指出，这与 CSRF 防护存在重叠并容易混淆；有些人把两者混为一谈，也有人坚持 CSRF 仍然必须单独处理。

预检、“简单”请求与边缘情况

  • 许多 CORS 陷阱都源于以下区别：
    • “简单”请求（GET、某些带特定内容类型的 POST）会绕过预检。
    • “非简单”请求（例如 JSON POST、自定义请求头）需要 OPTIONS 预检和明确的 CORS 许可。
  • 示例展示了，宽松的 Content-Type 检查（例如接受 text/plain 或表单编码中的 JSON）会绕过基于预检的假设。
  • 评论者强调，潜在有破坏性的行为绝不能通过像 GET 这样的“安全”或简单方法暴露出来。

误用与误解

  • 常见模式：开发者为了让功能跑起来，直接“设置 Access-Control-Allow-Origin: *”，却忽视了安全影响。
  • 有些人错误地认为 CORS 可以阻止其他网站或爬虫根本调用 API；也有人纠正说，不使用浏览器或禁用 CORS 的客户端不会受到影响。
  • Zoom 的 localhost 示例被认为具有误导性：CORS 头并不会像暗示的那样完全“限制”访问。

开发者体验与学习

  • 调试被描述为痛苦：浏览器报错信息晦涩，开发者工具视图令人困惑，而真正原因（服务器头）被隐藏了。
  • 许多人把 CORS 看作“设置好就忘”的东西；每次又得重新学习，然后再忘掉。
  • 有人推荐 MDN 的 CORS 文档，并建议先理解 SOP；也有人认为规范和文档过于复杂，因此这个协议实际上“很糟糕”。

架构与替代方案

  • 一种观点认为：最好的做法是通过反向代理让前端和后端部署在同一源上，从而完全避开 CORS。
  • 反方观点是：现实中的架构通常确实需要不同源，因此理解并配置 CORS 仍然是必要的。