浏览器跨域/CORS

根据 时间线 Chrome 80 稳定版本将在 2020-02-04 发布。 它的 变更列表 中有两项 Cookie 安全 相关的变更， 对非安全连接下的 Cookie 设置和 Cookie 跨于发送做了更多限制。 这意味着通过 Cookie 跨域跟踪用户的相关功能可能会受到影响（比如日志、统计）， 且只能在 HTTPS 上修复（意味着可以避免针对非安全连接的 MitM 攻击）。 具体地，有这两个 feature： Reject insecure SameSite=None cookies Cookies default to SameSite=Lax 对应的标准草案可以在 IETF 网站找到：Incrementally Better Cookies。 下文关注这两个变更对业务带来的影响，以及可能的应对方案。

随着 PWA 进入人们的视野，Fetch 作为除了 AJAX 之外的第二个 JavaScript HTTP API 开始引起人们的关注。 Service Worker 中通常利用该 API 进行真正的网络请求并应用相应的缓存策略。 本文简要介绍 Fetch API 的使用，Service Worker 与 Window 中的实现差异，以及跨域 Fetch 的问题。 目前 Web 异步应用都是基于 XMLHttpRequest/ActiveXObject 实现的， 这些对象不是专门为资源获取而设计的，因而它们的 API 非常复杂，同时还需要开发者处理兼容性问题。 虽然开发者普遍使用 $.ajax() 这样的上层包装，但 Fetch API 意在提供更加方便和一致的原生 API， 同时统一 Web 平台上的资源获取行为，包括外链脚本、样式、图片、AJAX 等等。

TL; DR 非 简单请求 不可重定向，包括第一个 preflight 请求和第二个真正的请求都不行。 简单请求可以重定向任意多次，但如需兼容多数浏览器，只可进行一次重定向。 中间服务器应当同样配置相关 CORS 响应头。

我们知道借助 Access-Control-Allow-Origin 响应头字段可以允许跨域 AJAX， 对于非 简单请求，CORS 机制跨域会首先进行 preflight（一个 OPTIONS 请求）， 该请求成功后才会发送真正的请求。 这一设计旨在确保服务器对 CORS 标准知情，以保护不支持 CORS 的旧服务器。 Wikipedia: https://upload.wikimedia.org/wikipedia/commons/c/ca/Flowchart_showing_Simple_and_Preflight_XHR.svg

在 Web 页面中可以随意地载入跨域的图片、视频、样式等资源， 但 AJAX 请求通常会被浏览器应用同源安全策略，禁止获取跨域数据，以及限制发送跨域请求。 虽然 有多种方法利用资源标签进行跨域，但能够进行的数据交互非常有限。 在 2014 年 W3C 发布了 CORS Recommendation 来允许更方便的跨域资源共享。 默认情况下浏览器对跨域请求不会携带 Cookie，但鉴于 Cookie 在身份验证等方面的重要性， CORS 推荐使用额外的响应头字段来允许跨域发送 Cookie。

这些办法大致可以分为两类： 一类是 Hack，比如通过 `title`, `navigation` 等对象传递信息，JSONP 可以说是一个最优秀的 Hack。 另一类是 HTML5 支持，一个是 `Access-Control-Allow-Origin` 响应头，一个是 `window.postMessage`。 跨域的正道还是 HTML5 提供的 CORS 头字段以及 `window.postMessage`， 可以支持 POST, PUT 等 HTTP 方法，从机制上解决跨域问题。