对于跨域问题的新认识

无论是前端同学还是后端同学，可能都接触过跨域问题。网上已经有了很多介绍跨域问题和解决方案的博客文章，笔者之前也是看过很多关于跨域问题的文章，当时感觉已经了解得差不多了，不过最近又有了一些新的认识，所以写这篇文章记录一下，希望也能对读者有所帮助。当然，本文是笔者自己的认识和实践，如果有不准确的地方，还请不吝指教。

 

在正式介绍之前，大家可以先思考一下下面几个问题：

1、跨域问题是浏览器导致的还是服务端导致的？

2、为什么在服务端配置几个响应头就可以解决跨域问题？

3、发生跨域问题时，请求发送出去了没有？服务端有没有接收到请求，有没有进行处理和响应？

4、为什么在浏览器里发送Ajax请求会发生跨域，但是在浏览器地址栏直接请求接口或者通过postman却不会有问题？

5、跨域问题（或者说背后的同源策略）到底保护的是谁？

这几个问题是笔者最近重新认识或者是重新确认的问题。本文主要是围绕上面的几个问题展开的，对于一些基础知识（如同源策略等）则不会赘述，还请大家自行百度。

 

对于问题1，大家应该都知道答案——浏览器，具体来说是浏览器同源策略的限制。

 

既然是浏览器的限制，那浏览器限制的是什么，请求还是响应？最开始笔者也是认为是限制了请求，跨域问题发生的时候，浏览器拦截了请求，没有发送出去。但是这种理解无法解释问题2，如果请求没有发送出去，也就是请求根本就没有到达服务端，服务端的配置又有什么用呢？

实际上，浏览器限制的是响应。

这个问题也比较容易验证，读者可以在本地启动一个服务端测试接口，用来接收前端页面的请求（设置断点或者打印日志来确认请求是否接收成功），比如接口地址为：http://localhost:8080/test，然后再写一个前端页面，通过 Ajax 方式请求后端接口，需要保证前端页面的访问也是通过域名访问的（比较简单的方式是使用 python -m SimpleHTTPServer 8000），比如访问地址是：http://localhost:8000/test.html。最终的结果证明，发生跨域报错时，请求已经发送出去了，而且服务端接收了请求并且进行了正常的处理。

 

确认了限制响应这个问题，那么问题2和问题3就迎刃而解了。

 

对于问题4，其实也容易理解。大家可以回到“同源”和“跨域”这两个词本身，对于直接发出的请求，无论是从浏览器的地址栏发出的请求，还是 postman 发出的请求，还是 Java 程序发出的请求，根本没有当前域的概念，实际上每发出一个请求，都是在独立请求一个资源，而不是在一个网站返回的页面里，再去请求另外一个网站/端口的资源，自然也就不会造成跨域了。

 

对于问题5，其实是要解释限制响应这种方式，对于服务端来说是没有保护作用的。要解释这个问题，还是要回到同源策略，这是浏览器的安全策略，虽然也是要保护用户的数据，但是是从浏览器的角度出发的。简单说是要浏览器保证在A域名下谨慎接收B域名返回的资源，防止B域名返回的资源是窃取A域名用户数据的恶意资源，这种保护只是最基础的保护机制（也可以说是最弱的保护），你不能指望同源策略来完全保护用户数据。对于用户数据的保护，主要工作还是在服务端完成，服务端要保证请求是合法的、是已经鉴权的。

 

以上便是读者最近关于跨域问题的新认识。

 

在这里提一下，同源策略是一个非常核心、非常基础的策略，是 Web 前端安全的核心，网上有人说，

《Web前端黑客技术揭秘》，非常系统的解析了前端安全知识，这些知识都是要围绕着同源策略展开的，可想而知它是有多重要

对于同源策略的理解，当前也只是停留在大概是什么、大概能解决什么问题的阶段，对于理解跨域问题已经基本足够，但是对于具体的场景还是理解不多，希望日后能有机会再整理一篇关于同源策略的深度文章，可能那时候对于跨域也会有更深的理解。

 

 

参考文章：

浏览器的同源策略

https://developer.mozilla.org/zh-CN/docs/Web/Security/Same-origin_policy

浏览器同源政策及其规避方法，阮一峰

http://www.ruanyifeng.com/blog/2016/04/same-origin-policy.html

不要再问我跨域的问题了

https://segmentfault.com/a/1190000015597029