同源策略
同源策略（Same-Origin Policy, SOP） 是一种Web浏览器的安全机制，旨在防止不同来源的恶意网页相互访问用户的敏感数据，以保护用户的隐私和安全。同源的概念基于以下三个要素：
- 协议（如
http和https） - 域名（如
example.com） - 端口（如
80和443）
同源策略规定，只有当两个URL的协议、域名、以及端口号完全相同时，它们才被视为相同源（Same-Origin），并可以互相访问资源。这一机制主要限制了JavaScript代码和文档对象模型（DOM）的跨源交互。
XHR的同源策略
XMLHttpRequest（XHR） 是一种用于在客户端与服务器之间进行数据通信的API。XHR同源策略规定，页面只能向与其相同源的服务器发送请求并接收响应。假如一个网页在 example.com 上运行，它只能通过XHR请求访问该域的数据，而不能请求其他域名下的资源。
举例来说：
- 允许：从
example.com/page发送请求到example.com/api - 不允许：从
example.com/page发送请求到another-domain.com/api
Cookie的同源策略
Cookie 也是同源策略的关键组成部分。当一个网页在浏览器中设置了Cookie，这个Cookie只能被同源的页面访问。这意味着只有具有相同协议、域名和端口的页面才能读取或发送这些Cookie，防止跨站点的Cookie劫持或滥用。
XHR与Cookie的同源策略差异
对于子域名，同源策略在XHR和Cookie处理上有所不同：
- XHR限制严格：子域名无法通过XHR访问父域名的资源，反之亦然。
- Cookie共享：Cookie默认可以在父域名和子域名之间共享。例如，
example.com的Cookie可以在sub.example.com中使用，前提是Cookie的Domain属性已正确设置。
CORS（跨源资源共享）
跨源资源共享（Cross-Origin Resource Sharing, CORS） 是一种允许浏览器从不同源请求资源的机制。它通过服务器配置的HTTP头部来明确声明哪些域名能够访问其资源，从而打破了同源策略的限制。
CORS的关键头部
CORS机制通过在请求和响应中添加特定的HTTP头部来管理跨源请求。以下是一些重要的CORS相关头部：
- Origin：标识发起请求的来源（浏览器会自动添加）。
- Access-Control-Allow-Origin：指定哪些源被允许访问资源。例如，可以设为特定域名或者通配符
*，以允许所有域请求。 - Access-Control-Allow-Methods：定义被允许的HTTP请求方法，如
GET、POST、DELETE等。 - Access-Control-Allow-Headers：列出允许客户端使用的自定义请求头部。
- Access-Control-Expose-Headers：指定哪些头部可以在客户端代码中访问到。
简单请求（Simple Request）
CORS定义了一种特殊情况——简单请求，浏览器可以不进行预检而直接发送请求。满足以下条件的请求通常被视为简单请求：
- 使用的HTTP方法是
GET、POST或HEAD。 - 请求头中只包括安全的头部，如
Accept、Content-Type（其值限定为application/x-www-form-urlencoded、multipart/form-data或text/plain等）。
如果请求不满足这些条件，浏览器将视其为复杂请求，并首先发送预检请求。
CORS预检请求（Preflight Request）
对于复杂请求，浏览器在发送实际请求之前，会通过 OPTIONS 方法向目标服务器发出一个预检请求。该请求询问服务器是否允许跨源请求以及允许的请求方法、头部等。服务器收到预检请求后会返回一个响应，明确指出哪些操作被允许，浏览器根据这些信息决定是否继续发送实际请求。
CORS的安全性
尽管CORS提供了跨源请求的便利性，但如果不正确配置，可能会导致安全隐患。特别是，如果服务器随意允许所有来源访问，可能会使应用程序暴露在跨站点请求伪造（CSRF）或其他攻击之下。因此，服务器在响应中应严格指定允许的源、方法和头部，并小心处理允许跨源请求的资源类型，确保不引发敏感数据泄露问题。
总结
同源策略和CORS是Web安全的核心机制之一。通过同源策略，浏览器可以有效限制跨源请求和数据访问，防止恶意网页窃取敏感信息。而CORS提供了一种合法打破同源限制的方式，允许不同域之间安全、受控地共享资源。然而，CORS的使用需谨慎配置，以避免潜在的安全问题。
