同源策略：为什么XMLHttpRequest不能跨域请求资源？

一.浏览器安全

浏览器安全可以分为三大块——Web页面安全、浏览器网络安全****和浏览器系统安全
假设，如果页面中没有安全策略的话，Web世界会是什么样子的呢？

Web世界会是开放的，任何资源都可以接入其中，我们的网站可以加载并执行别人网站的脚本文件、图片、音频/视频等资源，甚至可以下载其他站点的可执行文件。

Web世界是开放的，这很符合Web理念。但如果Web世界是绝对自由的，那么页面行为将没有任何限制，这会造成无序或者混沌的局面，出现很多不可控的问题。

比如你打开了一个银行站点，然后又一不小心打开了一个恶意站点，如果没有安全措施，恶意站点就可以做很多事情：

● 修改银行站点的DOM、CSSOM等信息；
● 在银行站点内部插入JavaScript脚本；
● 劫持用户登录的用户名和密码；
● 读取银行站点的Cookie、IndexDB等数据；
● 甚至还可以将这些信息上传至自己的服务器，这样就可以在你不知情的情况下伪造一些转账请求等信息。
所以说，在没有安全保障的Web世界中，我们是没有隐私的，因此需要安全策略来保障我们的隐私和数据的安全。

这就引出了页面中最基础、最核心的安全策略：同源策略（Same-origin policy）。

二.什么是同源策略

如果两个URL的协议、域名和端口都相同，我们就称这两个URL同源。

https://www.baidu/?category=1
https://www.baidu/?category=0

浏览器默认两个相同的源之间是可以相互访问资源和操作DOM的。两个不同的源之间若想要相互访问资源或者操作DOM，那么会有一套基础的安全策略的制约，我们把这称为同源策略。

具体来讲，同源策略主要表现在DOM、Web数据和网络这三个层面。

第一个，DOM层面。同源策略限制了来自不同源的JavaScript脚本对当前DOM对象读和写的操作。
第二个，数据层面。同源策略限制了不同源的站点读取当前站点的Cookie、IndexDB、LocalStorage等数据。由于同源策略，我们依然无法通过第二个页面的opener来访问第一个页面中的Cookie、IndexDB或者LocalStorage等内容。
第三个，网络层面。同源策略限制了通过XMLHttpRequest等方式将站点的数据发送给不同源的站点

三.安全和便利性的权衡

安全和便利性的权衡
我们了解了同源策略会隔离不同源的DOM、页面数据和网络通信，进而实现Web页面的安全性。

不过安全性和便利性是相互对立的，让不同的源之间绝对隔离，无疑是最安全的措施，但这也会使得Web项目难以开发和使用。因此我们就要在这之间做出权衡，出让一些安全性来满足灵活性；而出让安全性又带来了很多安全问题，最典型的是XSS攻击和CSRF攻击
1.XSS攻击
XSS全称是Cross Site Scripting，为了与“CSS”区分开来，故简称XSS，翻译过来就是“跨站脚本”。XSS攻击是指黑客往HTML文件中或者DOM中注入恶意脚本，从而在用户浏览页面时利用注入的恶意脚本对用户实施攻击的一种手段。

最开始的时候，这种攻击是通过跨域来实现的，所以叫“跨域脚本”。但是发展到现在，往HTML文件中注入恶意代码的方式越来越多了，所以是否跨域注入脚本已经不是唯一的注入手段了，但是XSS这个名字却一直保留至今。

当页面被注入了恶意JavaScript脚本时，浏览器无法区分这些脚本是被恶意注入的还是正常的页面内容，所以恶意注入JavaScript脚本也拥有所有的脚本权限。下面我们就来看看，如果页面被注入了恶意JavaScript脚本，恶意脚本都能做哪些事情。

● 可以窃取Cookie信息。恶意JavaScript可以通过“document.cookie”获取Cookie信息，然后通过XMLHttpRequest或者Fetch加上CORS功能将数据发送给恶意服务器；恶意服务器拿到用户的Cookie信息之后，就可以在其他电脑上模拟用户的登录，然后进行转账等操作。
● 可以监听用户行为。恶意JavaScript可以使用“addEventListener”接口来监听键盘事件，比如可以获取用户输入的信用卡等信息，将其发送到恶意服务器。黑客掌握了这些信息之后，又可以做很多违法的事情。
● 可以通过修改DOM伪造假的登录窗口，用来欺骗用户输入用户名和密码等信息。
● 还可以在页面内生成浮窗广告，这些广告会严重地影响用户体验。
除了以上几种情况外，恶意脚本还能做很多其他的事情，这里就不一一介绍了。总之，如果让页面插入了恶意脚本，那么就相当于把我们页面的隐私数据和行为完全暴露给黑客了。
恶意脚本是怎么注入的:
通常情况下，主要有存储型XSS攻击、反射型XSS攻击和基于DOM的XSS攻击三种方式来注入恶意脚本。
这三种攻击方式的共同点是都需要往用户的页面中注入恶意脚本，然后再通过恶意脚本将用户数据上传到黑客的恶意服务器上。而三者的不同点在于注入的方式不一样，有通过服务器漏洞来进行注入的，还有在客户端直接注入的。

针对这些XSS攻击，主要有三种防范策略，第一种是通过服务器对输入的内容进行过滤或者转码，第二种是充分利用好CSP，第三种是使用HttpOnly来保护重要的Cookie信息。

当然除了以上策略之外，我们还可以通过添加验证码防止脚本冒充用户提交危险操作。而对于一些不受信任的输入，还可以限制其输入长度，这样可以增大XSS攻击的难度。

为了解决XSS攻击，浏览器中引入了内容安全策略，称为CSP。CSP的核心思想是让服务器决定浏览器能够加载哪些资源，让服务器决定浏览器是否能够执行内联JavaScript代码。通过这些手段就可以大大减少XSS攻击。
2.CSRF
跨站请求伪造（英语：Cross-site request forgery），也被称为one-click attack或者session riding，通常缩写为CSRF或者XSRF，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。跟跨网站脚本（XSS）相比，XSS利用的是用户对指定网站的信任，CSRF利用的是网站对用户网页浏览器的信任。

四.跨域资源共享和跨文档消息机制

默认情况下，如果打开a页面，在a页面中通过XMLHttpRequest或者Fetch来请求b页面中的资源，这时同源策略会阻止其向b页面发出请求，这样会大大制约我们的生产力。

为了解决这个问题，我们引入了跨域资源共享（CORS），使用该机制可以进行跨域访问控制，从而使跨域数据传输得以安全进行。

在介绍同源策略时，我们说明了如果两个页面不是同源的，则无法相互操纵DOM。不过在实际应用中，经常需要两个不同源的DOM之间进行通信，于是浏览器中又引入了跨文档消息机制，可以通过window.postMessage的JavaScript接口来和不同源的DOM进行通信。

总结
同源策略会隔离不同源的DOM、页面数据和网络通信，进而实现Web页面的安全性。

不过鱼和熊掌不可兼得，要绝对的安全就要牺牲掉便利性，因此我们要在这二者之间做权衡，找到中间的一个平衡点，也就是目前的页面安全策略原型。总结起来，它具备以下三个特点：

页面中可以引用第三方资源，不过这也暴露了很多诸如XSS的安全问题，因此又在这种开放的基础之上引入了CSP来限制其自由程度。
使用XMLHttpRequest和Fetch都是无法直接进行跨域请求的，因此浏览器又在这种严格策略的基础之上引入了跨域资源共享策略，让其可以安全地进行跨域操作。
两个不同源的DOM是不能相互操纵的，因此，浏览器中又实现了跨文档消息机制，让其可以比较安全地通信。