跨域

跨域

概述

对象

浏览器内的请求发起方与被请求方

鉴定

协议

端口

ie在对DOM访问的限制上不对比端口

域名

强调：跟ip没半毛钱关系

跨域限制（同源策略）是浏览器的策略，因为浏览器是开放环境，用户可以输入任意的网址。所以并不存在App(非浏览器型)请求跨域，也不存在桌面程序、服务器程序有跨域的说法。是否跨域是由两方对比决定的，即请求方（当前浏览的网页）与被请求方（请求的地址，不一定是ajax）

限制什么

跨域读取远程资源

CORS请求结果

《HTTP访问控制（CORS）》

ajax请求

XMLHttpRequest

Fetch

未改变mode的情况，mode默认为“cors”

Fetch是对Request与Response的封装

显示指定crossorigin属性的img/script/link/video/audio/object等标签

css中的@font-face

webgl加载纹理

Worker/SharedWorker加载脚本

嵌入资源内容

script标签内部报错会被简化为简单的：script error

img、video等标签内容绘入canvas会污染画布，获取canvas数据会失败

link标签（好像没什么影响，隐私问题见备注）

iframe嵌入，无法读取其BOM及DOM

window.open打开的页面，无法读取其BOM及DOM

混合内容（Mixed Content）

禁止https页面以任何方式读取http资源。本是一条CSP，现代浏览器默认已经开启

注意：限制远程资源读取，并不限制其请求（不违反CSP前提下）。读取指：开发者通过js读取其内容

跨域本地存储存、取

Web Storage

IndexedDB

Cookie

此处特指CORS请求时，无法自动提交或写入Cookie

加菜：Javascript操作Cookie遵循的并不是一般所谓的同源策略，这点很多网上的文章写的都是错误的比如：在不设置Secure属性的情况下，cookie不区分http和https，同时意味着端口也是不区分的。再比如：x.a.com与y.a.com共享domain为.a.com的cookie

cookie安全四大金刚

domain设置

secure设置

samesite设置

httponly设置

不限制什么

不违反CSP的情况下向服务器发起请求意味着我们的跨域请求可以正常到达服务器

cors请求均可正常到达服务器

简单请求可直达服务器

非简单请求之前有预检请求，预检请求的响应结果不令浏览器满意的话，真实请求还是无法发出

跨域提交form表单（导致的CSRF、HFPA隐患不是这里考虑的)

会自动携带目标域存在本地的Cookie，所能携带的Cookie受setCookie时的指令有关（SameSite，Secure）此处对目标域的定义，并不是同源策略，理由同上

link、script、image、video、iframe等未明确指定crossorigin属性的资源嵌入请求

携带cookie规则同上

JSONP的实现就是利用了该特性

为什么限制

我们从反面来分析该问题，若不限制会怎样（Cookie策略默认）

本地存储无法被跨域获取这个就不用讲了，你在a.com的存储信息肯定不希望在访问一次evil.com后被其拿走这是浏览器作为公共网络的容器需要保证的最底线安全，而前端安全中涉及的XSS则是在想办法绕过(伪)该限制

跨域ajax请求：内网鉴权不再安全，比如a.com只能内网访问，黑客在其网站evil.com上通过ajax请求获取a.com内容然后诱导内网用户访问，则可将其作为跳板拿到了内网内容

跨域DOM/BOM操作，这主要体现在iframe及window.open上，如果evail.com上嵌入a.com的网站，诱导用户访问evail.com由于iframe嵌入网站会默认使用用户已经登录的凭据，则黑客可以拿到用户在a.com的各种隐私信息

为何限制跨域远程资源读取

为何限制跨域本地数据读取

怎么应对

绕过（仅供测试，非常不安全）

Chrome

Firefox

Safari

IE

CORS

如何配置请详细看此文

几个要点

服务器并不直接干预跨域的事情，也就是任何请求均可正常到达后端服务（哪怕是Options请求，ng之类的服务器默认也是会直接转发到后端服务）

ng之类的服务器不处理简单请求，响应时通过Access-Control-*-*系列响应头表明自己对于跨域的态度

简单请求

CORS相关响应头

浏览器在用户发起非简单请求之前，应该先发送Options请求并携带告知服务端接下来正式请求的Method与携带的自定义Headers

非简单请求

不符合简单请求的既是非简单请求

Options请求（预检请求）

ng之类的服务器应该处理Options请求，并直接响应204/200状态，并通过Access-Control-*-*系列响应头表明自己对于跨域的态度

浏览器在收到服务的响应后，会根据服务端所表明的对于跨域的态度，决定是抛错还是执行请求结果回调

简单请求在指定携带Cookie的情况下会携带Cookie头给服务器，服务器则随时可携带Set-Cookie头响应给客户端但是，若服务端响头应未携带 Access-Control-Allow-Credentials: true。则：1. Set-Cookie的值会被忽略，不会写入浏览器2. Cookie头会触发浏览器报错，无法通过代码取得响应结果

服务器只是声明跨域许可情况，浏览器才会真正对跨域请求做处理

配置注意

CORS与Vary:Origin的爱恨纠葛

mdn

相关论文

web安全拓展

可高度定制的CSP---浏览器安全的终极策略

总结

1.同源策略是浏览器与服务器的君子协议，服务器负责声明，浏览器负责遵守，所以在你、浏览器、服务器三者之间真正维护你隐私安全的是浏览器，大部分情况下，服务端并不区分请求来源是否合法，只负责校验凭据是否正确，然后返回数据浏览器来决定是否将服务端响应的数据给到网站的代码逻辑中

2.跨域资源嵌入、跨域form表单提交都会携带目标域的cookie，这是csrf攻击的原理所在，此种情况黑客一般不关心返回数据（实际也拿不到返回数据），只是借用户自己的凭据骗取服务器的信任达到执行非用户意愿的行为：比如a.com下接口/api/changepwd是通过get方式修改密码的，黑客只需要在evail.com嵌入一个img标签 <img src=\"http://a.com/api/changepwd?pwd=123456\"> 然后诱导用户访问，则用户只是看了下黑客的网页，自己在a.com的密码就被修改为了123456（滥用JSONP的公司多有此问题）