跨源资源共享 （CORS）
设计的初衷
在 HTTP 的原始时代（没有 CORS 之前），浏览器有一个极度严格的同源策略：
- 网页
A绝对不能读取网页B的任何数据。完全禁止，没有任何商量的余地。
后来，Web 变得复杂了，开发者需要在一个域名下调用另一个域名的 API 。浏览器意识到：“如果完全禁止跨域，大家都没法合作了”。
于是，浏览器发明了 CORS：
- 核心逻辑：我依然默认禁止所有跨域行为（安全第一）。
- 共享机制：但是，如果资源拥有者（API 服务器）愿意，他可以通过 HTTP Header 明确声明：“我愿意与
指定的域名共享我的资源”。
所以，叫“跨域资源共享”，意思是：通过协议，把原本“私有”的跨域资源，在特定条件下变成“公有（共享）”的。
优势
对于两个前端域名，blog.cannian.space我自己信任的域名，和hacker.com一个恶意的域名，对于浏览器说他们俩是平等的，他们都可以调用api.cannian.space上的api。登录会用到的cookie，他是保存在api.cannian.space这个域上的，hacker.com如果也发送了一条api.cannian.space/login，浏览器也会把cookie加在hacker或者blog的登录请求里，发送给后端。后端不知道这个请求时api.cannian.space、blog.cannian.space还是hacker.com发过来的，他会响应这个请求，即使他时hacker.com发送过来的，返回响应的时候会在响应头里放着你在后端配置允许共享资源的域名，比如说blog.cannian.space。api.cannian.space是怎么样浏览器都允许响应的，因为是同源的，blog.cannian.space浏览器看到后端的CORS允许blog.cannian.space共享资源，浏览器也会允许这个响应，但是对于hacker.com的响应他一看他的响应的CORS没有提到他就会拒绝响应。 发现了吗，后端自始至终都没有发现谁的请求是谁的，他只是无脑的给他的响应加上CORS也就是我信任哪些域名可以访问我的api资源，如果默认不配置就是拒绝所有的跨域访问。然后响应回去之后由用户的浏览器来控制是否允许把响应交给网页。但是我们的api调试工具就不会拒绝跨域访问，对于他来说他是没有前端的概念的他只有请求和响应。所以说CORS自始至终都是浏览器推动的标准其实和后端关系不大，只不过他把握住着用户的入口倒逼后端添加CORS，不过这也是为了保证用户的信息安全，如果没有CORS那么hacker也能拿着api.cannian.space的cookie向服务器请求，并且返回得到响应信息。强制让后端按需响应，要么完全禁止，来实现用户信息的安全，但是其实对后端的保护并不大，服务器本身还是会把hacker发送的api.cannian.space的请求去执行返回去。你想要保护后端需要自己去判断来源去拒绝，浏览器没帮你做这事。相当于是白做的其实对后端，该执行的也都执行了，但是他却是让后端配置的，有点像为了安全的霸王条款。
示例
flask-cors
from flask_cors import CORS
ALLOWED_ORIGINS = ["https://blog.cannian.space"]CORS(app, origins=ALLOWED_ORIGINS, supports_credentials=True)# 用来告诉浏览器，允许这个被允许的域发送我的cookienginx
也可以加上cors头，让他统一处理跨域问题。
弊端
在 “写操作”（POST/PUT/DELETE） 场景下，CORS 根本挡不住请求的发起和执行。它更像是一张 “回执检查单”。
CORS 是“事后诸葛亮”
- 前端：发请求（带 Cookie）。
- 后端：收到请求 -> 执行数据库操作 -> 生成响应。
- 浏览器：收到响应 -> 检查 CORS。
- 最终结局：如果 CORS 不通过，浏览器把响应体“丢弃”。