零
最近知乎上居然连续有两个关于跨域的问题邀请我回答。
虽然网上写跨域的文章已经有很多很多，且跨域本来是一个来自浏览器端（前端）的「问题」。但是跨域问题是一定要后端配合来解决的，加之网上文章大多只是介绍跨域如今已经定下的规则，很少提到规则的由来，其实容易让人迷惑。
假如你是一个后端工程师，和你配合的前端经验不够丰富，而你又对跨域一无所知。当你们遇到跨域带来的浏览器端问题，bug可能根本无从查起。
所以还是写了这一篇。讲讲跨域。
一、跨域是个什么「问题」？
最常见到的跨域「问题」是这样：
- 我有一个域名
a.com和一个域名b.com - 我在
a.com上有一个接口a.com/api，会返回一些数据 - 我想在
b.com域名下的一个页面上访问a.com/api得到数据 - 浏览器阻止了我
直觉来讲这是一件挺奇怪的事情，我把上面的例子换成一个更实际的：
- 这篇知乎专栏文章，所在域名是
zhuanlan.zhihu.com - 知乎主站域名是
www.zhihu.com，用户数据的api就在这个域名下 - 这个页面被加载出来时，它还要异步加载我的用户数据然后展示出来，访问了
www.zhihu.com下的api - 这个操作被浏览器阻止了，于是我的用户数据显示不出来
（假如知乎后端没有做跨域的配置）
二、为什么不让我跨域？
因为在web交互的环境中，只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。
想象这样一个场景，如果世界上没有跨域限制，这时假如：
- 支付宝的转账操作是一个post请求，大概是
https://alipay.com/api/withdraw/?to_user=kindJeff&amout=1000 - 我写了一段ajax的post请求代码，请求连接是上面的url。然后我把这段代码嵌入我的网站
a.com - 你不久前登陆过支付宝，浏览器里保存了
alipay.com域名的cookie - 我让你访问
a.com，打开页面，于是在你不知情的情况下发出了post请求，你的钱就被转到我的账号里了
这就是跨站请求伪造（CSRF）。这是一个非常严重的后果，其利用的就是网站（上例的支付宝）对浏览器的充分信任。
所以浏览器一定会设置跨域限制，避免在用户和网站不知情的情况下发出请求。
三、JSONP——最常用的绕过办法
回忆一下上面zhuanlan.zhihu.com和www.zhihu.com的例子，我只是想要GET一些数据而已。
当遇到这种跨域问题不知怎么解决的时候，查询一下，会发现有两种解决办法：
- 如果是子域名下的页面想访问父域的api，如
zhuanlan.zhihu.com想访问zhihu.com的api，那可以在发请求前设置一下document.domain的值为zhihu.com。毕竟是子域，浏览器几乎没有做什么限制。（如我在一个油猴脚本里就这样用过greasyfork.org/zh-CN/scrip…） - 在非父子域关系的情况下，如
zhuanlan.zhihu.com和www.zhihu.com（或者a.com和b.com），就是被浏览器当作两个不同的域名的，一般就会使用JSONP了
JSONP本质上就是让数据变成js代码，使用script标签来加载数据。
如我的用户数据api本来是https://www.zhihu.com/api/v4/members/kindjeff，返回值为{"name": "kindJeff", "gender": 1}
想要通过JSONP实现在zhuanlan.zhihu.com下跨域拿到这个数据，需要做的是：
- 改造这个api，让他返回一段js代码而不是json数据。如改造成，你访问
https://www.zhihu.com/api/v4/members/kindjeff?callback=render，得到的响应会是render({"name": "kindJeff", "gender": 1}) - 在专栏文章页面，不使用ajax去拿取数据，而是嵌入一个script标签：
<script src="https://www.zhihu.com/api/v4/members/kindjeff?callback=render"></script> - 在专栏文章页面写好一个叫render的函数，用来渲染用户数据
因为浏览器并不限制script标签的src是要从哪里加载脚本，跨域问题似乎就被JSONP「绕过」了。
四、为什么JSONP可以？
再想一想，浏览器不做script来源的跨域限制，而且大家都喜欢用JSONP并且改造了大量的api响应，问题不是回到了原点吗？我有一个网站a.com，在里面嵌入了支付宝某个api的JSONP版本（也就是个script）；我骗你访问a.com；浏览器自动去加载script，也就去访问了这个api。
其实问题并没有回到原点，因为JSONP实际上受限很大。作为一个script标签，一是浏览器只会使用GET方法去请求它，二是请求它的时候不会携带cookie，三是能被改造成JSONP形式的api一定是纯粹用来GET数据的。
就算其他网站用这些JSONP改造过的接口，也不会对网站造成影响。
（所以后端开发者最好不要在GET操作里做非幂等的事，因为别人在他的网站里嵌入script或者img标签放你网站的url，浏览器就会发出一个不带cookie的GET请求）
那更复杂的跨域需求应该怎么办呢？比如我就是需要在zhuanlan.zhihu.com页面下，发post请求到www.zhihu.com域名下的api，而且还是要带cookie的。这时JSONP就完全用不上了。
五、跨域资源共享（CORS）
欢迎来到没有JSONP的世界。
我个人不喜欢用JSONP：一是因为JSONP是一种HACK，一种非标准行为，利用了script来做数据的事；二是它使得别人能直接在他的网页上使用你的数据（虽然还是阻止不了别人用一些后端代理的手段来获取数据，但至少能增加对方的成本）。
对于跨域的访问控制，是有HTTP标准的。这也是网上很多讲跨域的文章的主要内容，我就只简单介绍，跨域资源共享（CORS）把跨域行为分三类：
简单请求
如简单的GET和POST。
还是以zhuanlan.zhihu.com页面请求www.zhihu.com的api为例。
- 浏览器发出请求时，request里会带上
Origin头，值为zhuanlan.zhihu.com - 这时只需要api响应header里带的
Access-Control-Allow-Origin字段包含（匹配）了发送请求的页面所在的域名（zhuanlan.zhihu.com），浏览器就会认为合法，把数据接着使用。 - 否则，浏览器会拦截掉这段数据：没错，响应的数据已经放body里到达了客户端，而浏览器会阻止掉，让专栏页面里负责发ajax的那段js代码拿不到响应值。
这样的好处很明显：我只需要在服务器端（通常是网关这一层）配置好Access-Control-Allow-Origin，而我的代码逻辑不需要对来源站点区别对待，就阻止其他人纯前端的手段使用我的数据，做到HTTP访问控制。
预检请求
略微复杂一定的请求，如PUT和DELETE等，或者请求时添加了CORS安全的header之外的header（如自定义的）。
这时，正式发送跨域请求前，浏览器会先对目标api发出一个OPTIONS预检请求，这个请求里会带三个和跨域相关的header，其值为预检之后，正式发送api请求时将会使用的来源/方法/请求头。这三个header是：
- Origin
- Access-Control-Request-Method
- Access-Control-Request-Headers
看名称应该能大概知道对应什么了。预检请求的响应需要带着与它们对应匹配的header和值，这样浏览器才会去请求跨域api。
预检请求的出现，是因为PUT等复杂操作通常是非幂等的。如果像简单请求一样直接请求，发现响应不合理才去拦截响应值，这个时候后端的PUT操作里该执行的事情已经被执行过了。
（至于为什么POST这个非幂等语义的方法会是简单请求，我觉得应该是历史包袱。毕竟在CORS出现前，form表单里POST就是能跨域使用的。而早期的js很弱小，提交form之后页面会刷新跳转到目标地址，源地址是拿不到POST响应的数据的）
带cookie的请求
这种跨域请求才是最危险的，最严重情况下能实现上面举的支付宝转账例子。
所以这种请求要求响应头里Access-Control-Allow-Credentials为true，且Access-Control-Allow-Origin不能是通配符，防止后端开发者犯错。
关于CORS更具体的规则，可以在MDN查阅到详细的资料。
六、不让跨域请求？还可以直接跨网页
按照上面的规则，支付宝把CORS设置的非常详细和安全，在自己同公司的业务能访问支付宝接口的同时，让a.com这种网站再无可乘之机，没有办法跨域访问。
这时，你登上a.com，点了a.com网站上的一个按钮。你的钱还是消失了。
这就是点击劫持（clickjacking）。
实现原理可以如下：
- 假如支付宝有一个页面，页面上的按钮点击是转账1000元给kindJeff
- 我把这个页面作为一个
iframe放在a.com的网页上 - 我把这个
iframe设置为透明，在它的按钮位置下面放置一个可以看见的「下一页」按钮 - 你看见我的网页，毫无防备地点击了下一页，实际上点击的位置是转账按钮
这种「跨域」也有类似CORS的控制方式，即X-Frame-Options响应头。它的值有三种：
- DENY。表示该页面不允许在 frame 中展示，即便是在相同域名的页面中嵌套也不允许。
- SAMEORIGIN。表示该页面可以在相同域名页面的 frame 中展示。
- ALLOW-FROM uri。表示该页面可以在指定来源（uri）的 frame 中展示。
发现网页在iframe里，且X-Frame-Options响应头的值不符合要求，浏览器不会加载这个iframe。
