前言
在我们日常开发中在与后台联调的时候是不是会经常遇到CORS错误，作为一名前端开发大家应该都知道这个事浏览器同源策略导致的，如何解决这个问题相信大家都有自己团队的方法。如有不了解的可以看下我之前总结过文章跨域解决方案，本文主要来分析下跨域的原因，以及跨域涉及到的API。
SOP同源策略（源：协议 域名 端口）
在MDN中如此介绍同源策略：同源策略是一个重要的安全策略（也可以理解为一种规定），它用于限制一个origin的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。
- 关键词：限制 阻隔 恶意 减少
- 目的：为了提供一个安全页面操作环境，保护用户信息不被窃取。
- 阻止内容：大概可分为三类存储类（cookie访问 localstorage/sessionstorage访问） DOM类（iframe对DOM的操作 ） ajax类（ajax的请求）
下面介绍下同源策略限制的一些操作：
存储相关
- cookie：cookie我们应该都很熟悉了，用来存储一些验证/基础信息等,如果没有同源策略的限制那网站的cookie就无法保证安全性了
//在客户端cookie是通过document.cookie来设置的 document.cookie="***;***;" //另外在服务端也可以通过Set-Cookie来设置客户端的cookie
在cookie的设置中我们常用的一些设置属性都是以同源策略为基础的，如：path domain HttpOnly
- localstorage/sessionstorage：另外浏览器的另外一种存储方式也是在同源限制的情况得以安全的使用，必须要满足同源条件才能在网站中自由读取localstorage和sessionstorage
//在同源策略的限制下，我们只能获取当前域下的数据 localStorage.getItem("key")
请求相关
同源策略限制了我们不同源的网站的ajax请求会被阻止，这个我们在日常开发中也会经常遇到，在日常联调中我们本地请求后台接口（未处理的情况）肯定会报跨域错误。导致此原因我们要理解本质上同源策略并不禁止跨域请求，而是在请求后拦截了请求的返回。
//响应首部，用于预检请求中，列出了将会在正式请求的 字段中出现的首部信息 Access-Control-Allow-Headers:** //响应首部 预检请求的应答中明确了客户端所要访问的资源允许使用的方法或方法列表。 Access-Control-Allow-Methods:** //响应头指定了该响应的资源是否被允许与给定的origin共享 Access-Control-Allow-Origin:**
DOM相关
试想如果没有同源策略，攻击者只需要在钓鱼通过iframe引入他们想要攻击的网页，然后诱导用户通过钓鱼链接打开那么被攻击的网站，用户的操作对于攻击者而言便无秘密可言了。
//如果没有SOP，在钓鱼网站通过js可以随意后去当时的操作信息 <iframe src="*******"></iframe>
相关问题
为何同源策略下仍然需要防范CSRF攻击？
在上篇文章中说了web攻击的一种方式CSRF，上文已经说了防御的办法，本文就不再赘述，有兴趣的可以点开链接看看，那么既然有了同源策略的限制为何还能进行CSRF攻击？ 核心点我们要明白SOP限制的内容是什么，在SOP中是不会阻止接口请求而是拦截请求结果，如此攻击者就可以在攻击网站中通过html标签的方式绕过SOP拦截，如常用的img标签：
<img src=http://******?action=****>
所以说浏览器安全需要我们考虑到方方面面，不能仅仅一个视角去判断。要知道千里之堤溃于蚁穴，一个漏洞和一百个漏洞并无区别。
总结
同源策略可以说是浏览器安全的基石，试想如果你打开一个钓鱼网站，这个网站可以随意获取你当前浏览器同时打开的其他网站信息，那我们还有什么安全可言。了解同源策略更是我们每一名前端开发的必修课，前端安全问题也是我们必须面对的问题之一，个人觉得同源策略就是在浏览器中形成一个个沙箱环境，让我们可以安全的浏览各个网站。另外作为一名前端开发者我们一定要写安全的代码，做一个稳重的程序员，守好安全的第一道防线。
