为什么会有跨域问题出现
那么我们先要知道什么是跨域，这个熟悉又陌生的名词。跨域通常情况下是说在两个不同的域名之间无法进行正常的通信，或者说是无法获取其他域名下面的资源。为什么就不允许呢，是因为浏览器采用了同源策略。
什么是同源策略
官方解释是，同源策略限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互。这是一个用于隔离潜在恶意文件的重要安全机制。听着有点绕口，那我们先接下去看。
先明确同源的定义
所谓同源指的是，协议、域名、端口号都相同，只要有一个不相同，那么都是非同源。
浏览器在执行脚本的时候都会检查是否同源，只有同源的脚本才会被执行。而非同源的脚本在请求数据的时候，浏览器会报一个异常，提示拒绝访问。按照上图同源的规范，当http://www.baidu.com:8081/home去调用以下地址时，会被判定为非同源。
还有值得一提的是localhost和127.0.0.1虽然都指向本机，但也是非同源的。
解释完同源大家应该对上面所说的同源策略有所了解了吧，那么接下来我们举个例子来说明下同源策略。
我们熟知的Cookie一般用于辨别用户身份。用户请求了接口进行登录，服务端验证通过后会在响应头加入Set-Cookie字段，然后下次再发请求的时候，浏览器会自动将cookie附加在HTTP请求的头字段Cookie中，服务端就能知道这个用户已经登录过了。现在有个网站A，是个银行网站，你进行了登录。然后又去访问了网站B，如果网站B能拿到A网站的Cookie，那么网站B就可以冒充你通过Cookie请求网站A，然后你的票票就飞到别人的口袋里了，这就是典型的CSRF攻击(跨站请求伪造)。
还有种就是你去访问银行网站A，配合上一篇文章讲的DNS劫持，给你个钓鱼网站C，在网站C的代码里面是这样的
一模一样的页面，C网站如果能拿到A网站Dom的内容，那么你的票票也就凉凉了。
上面两个例子很好的说明了同源策略就是限制两个不同源之间的资源进行交互，有了这样的限制，你银行卡里的钱是不是就安全多了。
同源策略限制的情况有以下三种：
1、Cookie、LocalStorage和 IndexDB 无法读取
2、DOM 和 Js对象无法获得
3、AJAX 请求不能发送
注意：对于像 img、iframe、script 等标签的 src 属性是特例，它们是可以访问非同源网站的资源的。
看到这里大家都应该对跨域有了一定的了解了吧。虽然同源策略这些限制是必要的，但是有时很不方便，合理的用途也受到影响。
那么在日常的开发中，如何解决跨域问题
先举个简单的例子来说下遇到的问题，比如www.news.baidu.com和www.map.baidu.com两个网页一级域名相同，只是二级域名不同，被认为不同源，但是开发者希望登录信息cookie共享。
首先浏览器允许通过设置document.domain共享 Cookie。前端可以设置相同的document.domain，两个网页就可以共享Cookie了。
另外，服务器也可以在设置Cookie的时候，指定Cookie的所属域名为一级域名，比如.baidu.com。这样的话，二级域名和三级域名不用做任何设置，都可以读取这个Cookie。
这种方式只适合主域名相同，但子域名不同的iframe跨域。那么不同窗口不同页面的跨域通讯如果处理。
HTML5为了解决这个问题，引入了一个全新的API：跨文档通信 API(Cross-document messaging)。这个API为window对象新增了一个window.postMessage方法，允许跨窗口通信，不论这两个窗口是否同源。
开发过程中遇到最多的就是请求跨域，那么针对AJAX 请求不能发送这条同源策略的限制，有以下几个解决方案：
1、架设服务器代理，浏览器请求同源服务器，再由后者(比如Nginx)请求外部服务
2、JSONP
JSONP是服务器与客户端跨源通信的常用方法。最大特点就是简单适用，老式浏览器全部支持，服务器改造非常小。上面讲到在HTML标签里，一些标签比如script、img这样的获取资源的标签是没有跨域限制的，利用这一点，我们可以这样干
JSONP只能发GET请求，因为本质上script加载资源就是GET请求，但JSONP也可以利用form发起post请求
3、WebSocket
WebSocket是一种通信协议，使用ws://(非加密)和wss://(加密)作为协议前缀。该协议不实行同源政策，只要服务器支持，就可以通过它进行跨源通信。浏览器发出的WebSocket请求的头信息中有一个字段是Origin，用于表示该请求的请求源，即发自哪个域名，服务器可以根据这个字段，判断是否许可本次通信。
4、CORS
CORS是跨源资源分享(Cross-Origin Resource Sharing)的缩写。它是W3C标准，是跨源AJAX请求的根本解决方法。相比JSONP，CORS允许任何类型的请求。在使用CORS来访问数据的时候，客户端不需要更改任何数据访问逻辑。所有的一切工作都是在服务端及浏览器之间自动完成的。因此如果希望为一个系统集成CORS支持的时候，我们需要做的工作主要集中在服务端。使用Filter 处理跨域请求，服务端可以进行一些配置，其中Access-Control-Allow-Origin和Access-Control-Allow-Methods字段是必填的，还有些其他的配置比如是否允许发送Cookie等，这边就不多说了。
Access-Control-Allow-Origin：它的值要么是请求时Origin字段的具体值，要么是一个*，表示接受任意域名的请求
Access-Control-Allow-Methods：它的值是逗号分隔的一个具体的字符串或者*，表明服务器支持的所有跨域请求的方法。
关于CORS详解，可以搜索下阮一峰老师的《跨域资源共享CORS详解》。
至此，有关于跨域的内容就结束了。

一、跨域

①、广义的跨域？

跨域是指一个域下的文档或脚本试图去请求另一个域下的资源，这里跨域是广义的。

广义的跨域：

1、资源跳转：A链接、重定向、表单提交

2、资源嵌入： <link>、<script>、<img>、<frame>等dom标签，还有样式中background:url()、@font-face()等文件外链

3、脚本请求： js发起的ajax请求、dom和js对象的跨域操作等

②、狭义的跨域？

其实我们通常所说的跨域是狭义的，是由浏览器同源策略限制的一类请求场景。

③、什么是同源策略？

同源策略/SOP（Same origin policy）是一种约定，由Netscape公司1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS、CSFR等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个ip地址，也非同源。

同源策略限制以下几种行为：

1、Cookie、LocalStorage 和 IndexDB 无法读取
2、 DOM 和 Js对象无法获得
3、 AJAX 请求不能发送



④、常见跨域场景？

URL 说明 是否允许通信 http://www.demo.com/a.js http://www.demo.com/b.js 同一域名，不同文件或路径 允许 http://www.demo.com/lab/c.js http://www.demo.com:8000/a.js http://www.demo.com/b.js 同一域名，不同端口 不允许 http://www.demo.com/a.js https://www.demo.com/b.js 同一域名，不同协议 不允许 http://www.demo.com/a.js http://127.0.0.1/b.js 域名和域名对应相同ip 不允许 http://www.demo.com/a.js http://x.demo.com/b.js 主域相同，子域不同 不允许 http://demo.com/c.js http://www.demo1.com/a.js http://www.demo2.com/b.js 不同域名 不允许

⑤、跨域解决方案？

1、 通过jsonp跨域

2、 document.domain + iframe跨域

3、 location.hash + iframe

4、 window.name + iframe跨域

5、 postMessage跨域

6、 跨域资源共享（CORS）

7、 nginx代理跨域

8、 nodejs中间件代理跨域

9、 WebSocket协议跨域

原文链接：

https://www.cnblogs.com/sdcs/p/8484905.html

二、csrf攻击

①、什么是csrf攻击？

csrf 全称 Cross-site request forgery, 通常缩写为CSRF 或者 XSRF, 中文名跨站请求伪造，是一种挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。CSRF 攻击手段是通过发起改变状态的请求, 而不是窃取用户的数据, 因为攻击者无法得到服务器返回的响应

②、如何攻击？

攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并执行一些操作（如发邮件，发信息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去执行。这利用了web中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。

补充：还可能更改账号所绑定的邮箱地址或者密码等。

例子

假如 Alice 在 bank.com 向 Bob 汇款100，这时攻击者Maria想要欺骗Alice，让她给自己汇款10000, 那么攻击将会由以下两步骤组成:

创建一个 URL 或者 script
	
利用社交工程欺骗 Alice 执行代码
GET 场景

如果 bank.com 把查询参数放到 URL 中, 那么 Alice 向 Bob 转账的操作可以简化为如下:
GET http://bank.com/transfer.do?acct=BOB&amount=100 HTTP/1.1

Maria 根据 bank.com 网站请求的结构, 将 Bob 名字替换为她自己的, 还把金额变大:
http://bank.com/transfer.do?acct=MARIA&amount=100000

那么这个充满恶意的 URL ,被 Maria 放到 a 标签中, 并且利用欺骗语言吸引 Alice 点击:
<a href="http://bank.com/transfer.do?acct=MARIA&amount=100000">View my Pictures!</a>

或者放到一个 长度和宽度都为0 的图片的src 中(图片不用用户点击, 自己就发起请求):
<img src="http://bank.com/transfer.do?acct=MARIA&amount=100000" width="0" height="0" border="0">

如果这张图片放到邮件中, Alice 根本就不会发现什么. 然而浏览器还是会将请求提交到 bank.com 的后台中.

一个真实的事件是发生在2008 年的uTorrent exploit。

POST 场景

假设 bank.com 现在使用 post 请求来传递参数的, 那么这个请求可以简化为:

 

POST http://bank.com/transfer.do HTTP/1.1
...
acct=BOB&amount=100


这种情况下, a 标签和 img 标签都无法发送 post 请求, 但是可以使用 FORM 来完成:

 

<form action="<nowiki>http://bank.com/transfer.do</nowiki>" method="POST">
<input type="hidden" name="acct" value="MARIA"/>
<input type="hidden" name="amount" value="100000"/>
<input type="submit" value="View my pictures"/>
</form>


我们还可以利用 JavaScript 来让文档载入的时候就发送这个请求:

 

<body onload="document.forms[0].submit()">
<form action="..." method="POST">
.....
</form>


其他的 HTTP 请求方法场景

假设现在银行使用的是 PUT 将数据放到一个JSON 中发送到后台中:

 

PUT http://bank.com/transfer.do HTTP/1.1

{ "acct":"BOB", "amount":100 }


那么我们可以利用内嵌的 JavaScript :

 

<script>
function put() {
    var x = new XMLHttpRequest();
    x.open("PUT","http://bank.com/transfer.do",true);
    x.setRequestHeader("Content-Type", "application/json"); 
    x.send(JSON.stringify({"acct":"BOB", "amount":100})); 
}
</script>
<body onload="put()">


幸运的是这段 PUT 请求并不会发送, 因为 同源策略 的限制. 除非你的后台设置了

 

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: PUT


总结

不论是 GET 请求还是 POST 请求, 如果有账户名为Alice的用户访问了恶意站点，而她之前刚访问过银行不久，登录信息尚未过期，那么她就会损失10000资金。

原文链接：https://www.jianshu.com/p/d08f4b9f8271

 

 

域名相同
协议相同
端口相同
下面就举几个例子来帮助更好的理解同源策略。
URL
说明
是否允许通信
http://www.a.com/a.js
http://www.a.com/b.js    同一域名    允许
http://www.a.com/a.js
http://www.b.com/a.js    不同域名    不允许
http://www.a.com:8000/a.js
http://www.a.com/b.js    同一域名不同端口    不允许
https://www.a.com/a.js
http://www.a.com/b.js    同一域名不同协议    不允许
在JAVA中处理跨域问题，通常有以下两种常用的解决方法。
第一种解决方法
后台代码在被请求的Servlet中添加Header设置：
response.setHeader("Access-Control-Allow-Origin", "*");
PrintWriter out =null;
try
{
out = response.getWriter();
} catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
out.print("{'status':'ok'}");
out.flush();
out.close();
Access-Control-Allow-Origin这个Header在W3C标准里用来检查该跨域请求是否可以被通过，如果值为*则表明当前页面可以跨域访问。默认的情况下是不允许的。
在前端JS中需要向Servlet发出请求，请求代码如下所示：
$.ajax({
url: "your url",
type:"get or post",
dataType:"json",
data:{
....
},
success:function(data){
...
}
第二种解决方法
通过jsonp跨域请求的方式。JSONP和JSON虽然只有一个字母的区别，但是他们完全就是两回事，很多人很容易把他们搞混。JSON是一种数据交换的格式，而JSONP则是一种非官方跨域数据交互协议。
首先来说一下前端JS是怎么发送请求。代码如下所示：
$.ajax({
url:"your url",
type:"get or post",
async:false,
dataType : "jsonp",
//服务端用于接收callback调用的function名的参数
jsonp:"callbackparam",
//callback的function名称
jsonpCallback:"success_jsonpCallback",
success:function(data){
console.log(data);
},
error:function(data){
console.log(data);
}
});
这里的callbackparam和success_jsonpCallback可以理解为发送的data数据的键值对，可以自定义，但是callbackparam需要和后台约定好参数名称，因为后台需要获取到这个参数里面的值(即success_jsonpCallback)。
下面，最重要的来了，后台怎么样获取和返回数据呢。代码如下所示:
PrintWriter out =null;
String callback=req.getParameter("callbackparam");
String json=callback+"({'status':'ok'})";
try
{
out = resp.getWriter();
} catch (IOException e)
{
// TODO Auto-generated catch block
e.printStackTrace();
}
out.print(json);
out.flush();
out.close();
首先需要获取参数名为callbackparam的值，这里获取到的值就是“success_jsonpCallback”。然后将这个值加上一对小括号。小括号里放入你需要返回的数据内容，比如这里我返回一个JSON对象。当然你也可以返回其他对象，比如只返回一个字符串类型数据也可以。最后前端JS返回的数据就是这样的：
success_jsonpCallback({'status':'ok'})
浏览器会自动解析为json对象，这时候你只需要在success回调函数中直接用data.status就可以了。

 


首先, 在开篇, 我需要声明一点, 请善用搜索引擎, 百度即便是对于搜技术解决方案再垃圾, 也不可能你 跨域 这种基础的问题都找不到答案的, 跨域根本不算是什么大问题. 而且, 不要总是特立独行, 你只是个普通人, 胳膊永远是拧不过大腿的, 学会团队合作, 学会和后端沟通, 和技术总监沟通, 把你的意见发表出来, 并说出因为所以然.


为什么会有跨域这个问题

因为前端代码是跑在 浏览器 里的, 你的所有网路请求说白了就是 浏览器 帮你发出去的. 并不是什么 js 帮你发出去的, js只是一门语言, 他只是按照浏览器的要求, 语法的要求, 按照一定的规范和格式, 把数据发出去, 就是这样.
	
为什么后端没有跨域这个问题, 因为后端是跑在 系统 里面的
	
浏览器可以主动发起一个 跳过跨域 的网络请求(放弃吧! 和前端无关! 儿子控制不了爸爸), 但是他不会让你在 它的内核 里发起跨域请求. 浏览器是跑在 系统 里的, 后端写的程序也是直接跑在 系统 里的, 前端相当于是 浏览器的下属, 得听从 浏览器 的规则.
	
为什么浏览器不允许你去发送跨域请求? 很简单, 因为没有那家浏览器有那个能力自己造内核, 基本都是行业内比较知名的内核, 比如 chrome 的内核, 浏览器只是一个壳, 然后把内核嵌入进去, 你前端界面的渲染包括界面的展示, 并不是浏览器弄出来的, 而是内核渲染出来的.
	
既然这个问题明白了, 只要是个正常人, 都能明白了, 浏览器需要按照内核的要求, 来界定你是否可以发一个跨域请求出去. 非常不幸的告诉你, 是个正常的内核, 纯前端都是不允许发跨域请求的.
拆台杠精上线

博主, 我觉得你说的不对, 你看哈, 我要使用 vue-cli 建立的 webpack 项目, 配置了 proxyTable , 使用 npm run dev 跨域访问了! 你这说的不对, 前端是可以发跨域请求的!

首先, 请把这个单词翻译过来理解下: proxyTable, 是什么意思? 代理表, 什么是代理, 代理就是代替你请请求某个url并将结果返回给你, 谁给你代理? 并不是浏览器给你代理的, 是 vue-cli 下的 小型服务器 帮你去请求这个url的, 换言之就是, 你在网页上发起了一个 ajax 请求, 小型服务器会拦截你这个请求, 然后帮你发出去, 然后等对面回应了, 再将结果返回给你. 浏览器根本就管不到了. 浏览器这时候只负责的角色是: 这里有人要发起一个ajax请求了, 呐, 丢给你, 你去处理吧, 处理好了丢给我, 我再给他 , 是这样的, 明白不?
	
还有, 小型服务器只有在 npm run dev 模式下才有效, 也就是说, 只有在开发模式下代理表才生效, 如果你是构建的代码 npm run build 那个对不起, 没人给你拦截请求并代替你请求了, 又回归到浏览器的约束层, 明白不?
博主, 不行! 你说的还不对, 我就是觉得不对, 那你说, 为什么我自己请求你所谓的那个小型服务器就没有跨域的提示?

很简单, 因为你们符合 同源策略, 这个名词我再稍后再详细讲解, 对于浏览器而言, 你们是 一家人, 既然是一家人, 那浏览器还管你干嘛? 管多了还怪浏览器"多管闲事"呢. 而对于不符合同源策略的规则, 浏览器就类似于扮演着"银行"的角色, 你们都不是一个家人, 凭什么我让你从他的卡里取钱? 待会人家钱没了还怪我喽? 这傻X事情浏览器可不做.
什么是同源策略

同源策略, 通俗易懂的解释就是 界定你们是一家人的标志
	
如何才是一家人? 很简单, 协议, 域名, 端口 全部一致, 即可
	
举个例子: 你在本地跑一个项目, 端口是8080, 然后去请求百度的接口(打个比方), 肯定是不符合同源策略的, 你看, 你本地是什么地址? 127.0.0.1? localhost? 百度呢? baidu.com, 你看, 不一样吧. 你本地肯定是 http:// 打头吧? 百度呢? https:// 打头, 你看, 又不一样, 那百度的端口呢? 80(为什么是80这里不扩展了,懂的自然懂), 你呢? 8080, 如果是你, 你会觉得这两个玩意是一家人???
如何解决呢

如果您仔细阅读了上面的因为所以然, 那么您一定能猜到怎么解决问题了, 那很简单, 就是让浏览器 认为 你们是一家人, 就这样, 那怎么解决呢? 也很简单, 注意, 如下部分请给后端人员看, 纯前端我说的已经很清楚了, 无法处理跨域请求. 还不理解的在读一遍博文.


	
小伙伴, 首先, 你需要写一个拦截器, 然后把所有接口(假设你所有接口都需要前端去请求而不是自己用的话)拦截住, 然后统一修改请求头部分即可.

	
添加 Access-Control-Allow-Origin 字段, 表示允许那些域名访问接口, 图省事的话, 参数填写成星号即可(*), 及允许任何域名访问接口, 当然很显然, 这是不安全的, 部署上线阶段建议改为指定的域名
		
添加 Access-Control-Allow-Methods 字段, 表示允许那些类型的请求, 图省事也可以填写成星号(*), 这个一般对安全影响不到, 较真的话可以写成 GET,POST, 因为一般来说, 接口都只用这两种方式(不接受杠精)
		
如果您的身份验证机制还是 session 的话, 强烈建议您和您的老板说, 换成JWT的模式, 至于JWT是个什么鸟玩意自行百度或者我有时间再写吧! 前后端分离的模式标配 JWT, session的模式属于SSR那种模式的标配, 跑题了, 如果你的验证方式是 session 的话, 那么不好意思, 你还要添加一个 Access-Control-Allow-Credentials 字段, 参数为 true, 表示允许发送身份凭证(也就是所谓的sessionID)到接口, 前端的ajax请求还需要调整, 具体可看后面的博文), 这样, 您的后端程序, 才能通过 sessionID找到对应的某个用户, 然后就不用我说了, 你懂得...