CORS

概要

CORS（Cross-Origin Resource Sharing，跨源资源共享），是 Web 浏览器控制发往不同源（协议、域名、端口的组合）的请求的安全机制。浏览器默认采用同源策略（Same-Origin Policy），限制 JavaScript 发往不同源的请求。CORS 提供了一种机制，只放行来自服务器明确允许的源的请求。

为什么需要同源策略

如果没有同源策略，恶意网站就能经由用户的浏览器，向已登录的银行网站或社交媒体发送请求，并读取其响应。浏览器会自动附上 Cookie，所以即使是从攻击者网站发出的请求，也会在带着用户认证信息的状态下到达服务器。

CORS 被设计为一种“例外机制”，在维持这一策略的同时，让不同源之间正当的通信成为可能。

预检请求的机制

对于简单请求（GET、HEAD、带特定 Content-Type 的 POST）以外的、发往不同源的请求，浏览器会在正式请求之前，用 OPTIONS 方法发送“预检请求”。服务器用 Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers 等头部，回应允许的源、方法和头部。

浏览器确认预检的响应，只有在得到允许时才发送正式请求。通过这种两阶段的机制，服务器可以在处理实际请求之前，判断是否接受这个请求。

提问箱服务的 CORS 设计

前端和后端 API 在不同的源上运行时，就需要配置 CORS。如果用 CloudFront 把前端和 API 放在同一域名的不同路径下，源是相同的，所以不会发生 CORS 的问题。

这种“同源结构”是避开 CORS 复杂性的设计上的巧思。把 /api/* 路径路由到 API、其余路由到前端，在浏览器看来就全都是发往同一个源的请求。可以排除 CORS 头部配置错误造成的安全漏洞，以及预检请求带来的延迟增加。