由于浏览器同源策略使得不同源、不同域名、不同端口的Cookie无法读取、DOM和JS对象无法获取、AJAX不能发送，所以在写日常业务时常需要跨域
一、jsonp跨域(只能GET请求)
常见安全问题
1.JSON劫持，由于未校验referer来源，导致攻击者可以构造恶意页面诱导受害者访问接口，劫持敏感信息，从而导致csrf漏洞
2.callback自定义导致xss漏洞，由于未对JSON格式Content-Type做限制导致xss漏洞，如”?callback=foo(‘<img src=@ οnerrοr=alert(/xss/)>’)”
安全方案：
1.严格验证referer；部署一次性Token。
2.严格按照JSON格式输出Content-Type : application/json; charset=utf-8；对callback函数长度做限制，对特殊字符做过滤
二、websocket跨域
websocket支持双向通信，常用于即时通信，也可以用来跨域
常见安全问题：
1.在服务端websocket连接时未进行origin验证，导致跨域劫持漏洞
安全方案：
1.严格验证origin，reference
三、postMessage跨域：postMessage是H5新特性，利用postMessage不能和服务端交换数据，只能在两个窗口 <iframe> 之间交换数据。解决跨窗口跨域的情况
常见安全问题：
1.伪造接收端：由于发送端用法不当如targetWindow.postMessage(message,’*’)意味着任意域可以接受消息，容易造成敏感信息泄漏
2.伪造发送端：如果接收端没有校验消息来源，攻击者可以对接收端发送消息，如果接收端对消息处理不当，易造成xss漏洞
安全方案：
对发送端严格限制发送域，做白名单限制。对于接收端严格校验消息来源，严格处理orgin
四、window.name。
常见安全问题：
1.window.name跨域本质上利用浏览器特性进行跨域，不与服务端交互，使用不当时会造成安全问题。如果对接受源未做检测，有可能出现xss问题。
2.由于window.name特性，window.name可以数据容易被任意域名获取
解决方案：
1.当一个域接受另一个域数据时，要对其进行检测，防止不正当使用造成xss
2.禁止存储C2及以上敏感数据
五、document.domain方法，此方案仅限主域相同，子域不同的跨域应用场景。
将子域和主域都设置document.domain为基础主域，两个页面就实现了同域，从而实现跨域。
如果子域有xss漏洞那么可以直接跨同源攻击根域和同样设置了document.domain的其他子域
六、CORS跨域，只服务端设置Access-Control-Allow-Origin即可。
常见安全问题：
如果设置Access-Control-Allow-Origin: *，会允许所有域跨域，正确配置Access-Control-Allow-Origin
七、node中间件跨域通过设置代理服务器实现数据转发，与webpack-dev-server配置proxy跨域原理相同，代理跨域目标接口禁止设置为*，无大风险点
八、nginx代理跨域原理相同都是配置一个代理服务器，访问要跨域接口。
