跨域处理

最新推荐文章于 2025-08-23 21:55:20 发布
转载 最新推荐文章于 2025-08-23 21:55:20 发布 · 113 阅读 · 0 ·
CC 4.0 BY-SA版权
原文链接：https://juejin.im/post/5b4eb7166fb9a04f99639f5e
文章标签：

#后端 #json #前端 #ViewUI

跨域处理

同源策略

同源策略：Same Origin Policy

在讨论跨域之前，我们有必要解释下“同源策略”：

同源策略是浏览器的一种安全限制，它限制了从同一个源加载的文档或脚本如何与来自另一个源的资源进行交互，这是一个用于隔离潜在恶意文件的重要安全机制。

我们在前端开发过程中遇到的某些资源，如 DOM、Ajax/Fetch 返回的异步数据及浏览器本地存储的 Cookie、localStorage 等，一般会比较敏感。

想象以下场景，我们登录在线银行，这个站点依赖 Cookie 来保护我们的用户信息：只有正常登录认证过的用户，服务器端会在浏览器中存储一个生成的 Cookie 来标识这个用户，允许正常进行转账操作。而在浏览完这个站点后，我们又访问了一个恶意站点，如果没有同源策略限制，这个恶意网站也可以拿到银行站点存储的 Cookie 并传输给别人，那么在这个 Cookie 过期之前，别人可以把你的银行卡搬空。。

关于 DOM 操作也是一样的，虚假钓鱼网站以 iframe 的方式嵌入了真实网站，我们在访问时可能根本发现不了，如果没有同源策略限制，主页面可以任意操作子页面中 DOM 元素，比如在用户密码输入框上增加了额外的事件监听，同样可以诱导我们暴露个人敏感信息[^1]。

[^1]: 当然为了防止我们的站点被嵌入到钓鱼站点的 iframe 中，我们也可以通过 meta 声明、后端服务器设置等规避，如在 HTML 中增加如下 meta: <meta http-equiv="X-FRAME-OPTIONS" content="DENY">，其他设置将在 web 安全章节详细说明。

而我们经常见到的另一些资源，如 CSS 样式表文件、JS 文件、字体文件、图片等因为不具备敏感信息，所以不受同源策略限制，这些静态资源我们可以依赖 CDN 来部署和分发以提高用户体验：一方面 CDN 节点众多，可以就近响应用户请求；另一方面，浏览器在发起请求的时候会默认带上本域的 Cookie，而请求静态资源时明显不需要 Cookie 保护，每次请求都带 Cookie 增大了网络带宽消耗，我们的 CDN 域一般与我们的站点域不一致，可以规避这个问题。

判断跨域

同源：协议、域名、端口都相同。详情可以参见这里 。

示例：

URL结果原因
http://store.company.com/dir2/other.html成功
http://store.company.com/dir/inner/another.html成功
https://store.company.com/secure.html失败不同协议 ( https和http )
http://store.company.com:81/dir/etc.html失败不同端口 ( 81和80)
http://news.company.com/dir/other.html失败不同域名 ( news和store )

跨域数据存储访问

localStorage 与 IndexedDB

localStorage 和 IndexedDB 均遵循上述同源策略限制，它们不允许 JavaScript 对跨域数据进行读写操作。这限制了我们在不同子站点上共享数据的能力，如我们想在我们产品的两个站点见共享风格配置，用户切换了一个站点的风格（如导航为深色等）后，在同一浏览器中打开的另一个站点也保持同样的风格设置，依靠 localStorage 是做不到的，一般做法是存储在后端 Redis 等服务中，页面加载的时候读取下配置接口。

Cookie

Cookie 的作用域限制与 localStorage、IndexedDB 这些数据存储方案不同，它使用Domain 和 Path 来设置作用域。

因此我们可以使用 Cookie 来实现 localStorage 与 IndexedDB 章节中用户配置共享的例子，但需要注意，虽然我们可以用 Cookie 可以实现上述需求，但由于浏览器的每次请求都会携带符合条件的 Cookie 数据，这样无疑增大了带宽消耗，所以在实际项目中仍然建议配置信息存储在后端，由指定接口提供。

我们可以利用 Cookie 的 Domain 设置配合 Oauth 来实现指定子域名下所有站点的单点登录：*.xiaosansiji.com 是我们的一个泛域名解析，其下有 a.xiaosansiji.com、b.xiaosansiji.com 等多个站点，我们希望登录某个站点后，就可以默认登录所有 xxx.xiaosansiji.com 站点。

具体实现为：用户访问 a.xiaosansiji.com 站点时，跳转到单点登录服务器提供的统一登录页面，用户验证通过后重定向跳转回 a.xiaosansiji.com 主页面，在这次 HTTP 请求的 Response Header 中向浏览器中存储 Cookie 并设置 Domain 为 xiaosansiji.com ：

Response Header
HTTP/1.1 302
Server: nginx/1.13.1
Date: Wed, 04 Jul 2018 06:48:43 GMT
Content-Length: 0
Location: http://a.xiaosansiji.com/
Connection: keep-alive
Set-Cookie: csid=D6ACED5C8AB99D5A3DB57594112AB00F;domain=xiaosansiji.com;path=/;HttpOnly
Content-Language: zh-CN
复制代码

这样当我们在同一浏览器中新打开的一个 Tab 中访问 b.xiaosansiji.com 站点时，系统提示我们已经登录成功。

注意我们在 Set-Cookie 时使用了 HttpOnly 标记，这主要是从安全角度禁止 JavaScript 操作该 Cookie，详细内容参见 《Web 安全》章节。

跨域 HTTP 访问

在日常前端开发工作中，我们遇到的更多是上面这样的报错：我们从 localhost:8000 发起了一个 Ajax 请求到 www.google.com.hk 站点，然后我们没能拿到想要的数据，反而在 console 中提示了上图的错误。

这其实就是因为同源策略限制，我们的跨域请求失败了。需要注意其实我们的请求是已经发送到目标服务器了，对方接口也正常返回了数据，只是在返回到浏览器时被 block [^1]了（回想本篇开头的同源策略定义，它是浏览器的安全策略）。

[^1]: 高版本的 Chrome 和 Firefox 等会在站点采用 HTTPS 的情况下直接阻止请求发出去，这时候后端其实不会接收到该请求。

我们常见的解决方案有三种：

  • JSONP ：是把请求伪装成标签去请求。因为标签是浏览器自己发送请求，所以不受同源策略影响啊
  • 后端 Proxy：这个也很好理解，我把所有请求都发送到不跨域的代理服务器上，服务器上可是我们说的算，只要经过处理把数据返回给浏览器就好。
  • CORS：这是我们今天主要讲。因为解铃还须系铃人，既然是你限制的，那么你总得给我一个解决办法吧。浏览器给出的解决办法就是（CORS）

JSONP

JSONP：JSON with Padding

我们在使用 jQuery 等封装的 Ajax 库时经常这样使用 JSONP：

$.Ajax({
  type: "get",
  async: false,
  url: "http://demo.com/api/current?user=1",
  dataType: "jsonp",
  jsonp: "callback",//传递给请求处理程序或页面的，用以获得jsonp回调函数名的参数名(一般默认为:callback)
  success: function(json){
    alert(json);
  },
});
复制代码

这让我们产生了一种错觉，仿佛 JSONP 也是 Ajax 的一种，毕竟我们正常发起请求时也只是将 dataType 改为 json 而已。

但 JSONP 其实跟 Ajax/Fetch 都没什么关系，它用一种比较 hack 的方式实现跨域 HTTP 接口交互：在同源策略章节我们已经说过，在页面中使用 script 标签加载 CDN 上的 JavaScript 资源文件是不受同源策略限制的。程序员们就想到如果我们请求的 JavaScript 文件是后端动态生成的，在浏览器端执行了这一段 JavaScript 代码后岂不是就拿到了后端接口的数据！

于是上述代码的底层实现其实是这样的：

浏览器端我们需要增加如下代码发起请求，并声明了请求成功后处理函数

var callback = function(data){
    alert(data);
};
var url = "http://demo.com/api/current?user=1";
var script = document.createElement('script'); 
script.setAttribute('src', url); 
document.getElementsByTagName('head')[0].appendChild(script);
复制代码

在服务器端我们需要把正常返回的数据转化为字符串，并用 callback 包裹

server.on('request', function(req, res) {
  var params = qs.parse(req.url.split('?')[1]);
  // jsonp返回设置
  res.writeHead(200, { 'Content-Type': 'text/javascript' });
  res.write('callback' + '(' + JSON.stringify(params) + ')');
  res.end();
});
复制代码

这样页面上请求到后端数据后就可以直接调用 callback 方法进行后续数据展示处理了。

可以看到 JSONP 的底层实现跟 Ajax 的 XHR 完全不同，只是 jQuery 帮我们封装了这些操作而已。

JSONP 方案可以运行在任何允许执行 JavaScript 脚本的浏览器上，兼容性较好，但也存在很多限制：

  • 需要后端同学的支持：正常返回的 JSON 数据需要处理一下，变成浏览器可以执行的脚本
  • 仅支持 GET 方法的请求：如代码示例中展示的，我们只能发起 GET 请求，且所有参数只能添加到 url 中
  • 对于错误的支持不好：不像 Ajax 和 Fetch 都有较好的错误处理接口，JSONP 失败了只会在控制台输出一句 error 而已

总的来说，我们在日常与后端接口交互中较少采用 JSONP 方案，在投放广告等领域用的比较多。

###后端 Proxy

这是我们日常开发中最常用的方案，具体来说就是让后端启一个代理服务，来代替直接由浏览器对其他域的接口发起请求。

如，我们将站点部署在 Nginx 上，有两个单独部署的后端接口地址（这在后端微服务应用中很常见）需要访问：

server {  
    listen       80;  
    server_name  localhost;  

    #反向代理地址为http://a.demo.com/api的后端接口，需要根据实际情况改为自己的地址
    location ^~ /api {
        proxy_pass http://a.demo.com;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Host $http_host;
    }
    location ^~ /bpi {
        rewrite ^/bpi(.+) /api/$1 break;
        proxy_pass http://b.demo.com;
        proxy_set_header        X-Real-IP $remote_addr;
        proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header        Host $http_host;
    }
    ...
}
复制代码

这样我们在浏览器上发起这两类请求时其实都可以请求到这个 Nginx 节点上，由 Nginx 根据 url 路径的不同（api/bpi）来分别请求两个站点的接口。

后端 Proxy 的方案唯一的缺点就是需要后端开发或者使用 Nginx/Apach 等配置代理，只能用于后端能够改造的前提下。

CORS

CORS：cross-origin sharing 跨域资源共享

对于 Ajax 和 Fetch 来说，CORS 是现在最可靠的跨域解决方案，它本身已经加入 W3C 规范 。现在各主流浏览器都允许服务器端返回 HTTP 请求时增加相应 header 设置，以声明浏览器端发出的请求有权限做哪些操作。上节说过，同源策略会使得浏览器在服务端返回数据时阻塞该响应，而当我们在 Response header 中增加了相关 CORS 声明后，浏览器就可以放行该响应，让 JavaScript 继续后续的数据处理和展示工作。这相当于让服务器端为我们的请求“背书”，该服务器明确告知浏览器：我允许该站点跨域获取我的接口数据。

在 CORS 中的配置分为“简单请求”和“需预检的请求”两种。

简单请求

满足如下条件，视为“简单请求”：

满足以上条件的“简单请求”，我们只需要要求服务器端在返回响应时提供 Access-Control-Allow-Origin 的 header 设置就可以了，在线例子可以查看这里

HTTP/1.1 200 OK
Date: Thu, 05 Jul 2018 02:18:58 GMT
Server: Apache
Access-Control-Allow-Origin: http://arunranga.com
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: application/xml
复制代码

如上，我们在跨域的另一个服务器返回中设置了 Access-Control-Allow-Origin: http://arunranga.com ，即明确告知浏览器允许 http://arunranga.com 站点的请求获取本服务器的数据。

当然，有些提供天气/地理查询服务的网站可能会允许任何其他站点获取数据，则会设置 header 为 Access-Control-Allow-Origin: * 。

在有一种情况下，不允许设置 Access-Control-Allow-Origin: *：跨域请求的接口依赖 header 中的 Cookie 信息来做用户验证时，根据 CORS 规范，请求不会自动携带该域下的 Cookie，对于 Fetch 请求来说，我们需要设置

fetch(url, {
  credentials: 'include'  
})
复制代码

以允许携带 Cookie，具体情况可参考 Request.credentials。同时，我们只能设置Access-Control-Allow-Origin: http://arunranga.com ，即只能允许指定域的访问，而不能使用 * 允许来自所有域的访问。

需预检的请求

不满足“简单请求”条件的所有请求我们都视为“需预检的请求”，如 PUT 请求等。其特殊之处在于：我们不仅需要设置 Access-Control-Allow-Origin，还需要设置 Access-Control-Allow-Methods 等以允许这些请求。

在简单请求过程中，该跨域的请求与非跨域请求其实是一样的：都从浏览器端发送请求到了目标服务器，在浏览器接收到响应时再判断是否允许跨域处理。

而需预检的请求则不是这样：在发起的正式的 PUT 等请求前，浏览器会先使用 OPTIONS 方法发起一个预检请求，以询问服务器是否允许该请求，如果允许才会发送实际请求，可以查看这个在线例子：

在这个例子中，我们发起了一个 POST 请求，但因为我们使用了非标准的的 header 设置，所以仍属于需预检的请求。这也是比较常见的做法，在 header 中加入某些我们自己定义头，如标识用户所属的组织等：x-current-group: 'dev'，相应的在 CORS 处理中我们需要在增加允许该 header 的设置：Access-Control-Allow-Headers': 'x-current-group' 。

当然如果我们每发起一个需预检的请求都要实际上发送两次 HTTP 请求（一个 OPTIONS 预请求，一个正式请求），对于服务器来说增大了访问压力，我们可以在 Response header 中设置 'Access-Control-Max-Age': 600 来让验证通过后的10分钟内不再发送预请求。

常见 header 设置

总结以上简单请求和需预检的请求使用场景，常用的 CORS Response header 设置有:

其他 CORS 用法

注意 CORS 其实不仅限于跨域接口的访问，HTML 5 规范中也对 CORS 提供了支持，比如我们在做前端全局异常采集时经常要求引入的 Scripts 做如下处理：

<script src="https://example.com/example.js" crossorigin="anonymous"></script>
复制代码

它允许我们可以获取该跨域脚本执行出错时的详细信息，否则我们就只能在监听 window.onerror 时得到这样的提示：Script error.

其他标签支持 CORS 的情况，请参看这里 。

参考链接：

欢迎访问我的 github 仓库 ，最近在整理思路写前端知识库。

转载于:https://juejin.im/post/5b4eb7166fb9a04f99639f5e

yii跨域处理_Yii2+vue跨域问题解决
weixin_35102377的博客
12-23 1642
简介最近公司想提升档次,就拿我们的PC页面开刀(我觉得YII自带的views蛮好的啊,前端插件也很多),没办法,只能改了,遇到了一个坑就是跨域.跨域和同源跨域:就是跨域名，跨端口，跨协议例如：如果有两个服务器，服务器A和服务器B,服务器A上存储了php数据，script,甚至是css这些文件，而你在服务器B上只写了html，然后你所在的服务器B上动态创建script，css，php数据(使用aja...
springmvc跨域处理和过滤器方式跨域处理主要代码
04-08
CORS主要用于处理正规的跨域请求，而Filter则用于处理OPTIONS预检请求。Filter可以确保即使没有正确配置CORS，也能对OPTIONS请求进行适当响应。 请注意，允许所有来源（"*"）和所有头部可能会带来安全风险，因此在...
spring security跨域处理
LCY133的博客
04-10 1201
在 Spring Security 中处理跨域问题（CORS）需要明确配置允许的跨域请求规则，并确保 Spring Security 的过滤器链不会拦截合法的跨域请求。正确配置后，前端应用可安全地与后端 API 跨域通信，同时保持系统的整体安全性。：需同时启用 Spring Security 的 CORS 支持（：OPTIONS 请求被 Spring Security 拦截。：Spring Security 过滤器链未正确处理 CORS。：禁用 CSRF 会降低安全性，需确保其他防护措施到位。
iframe 跨域处理
weixin_46497861的博客
09-30 1577
iframe 跨域处理通信
Springboot跨域处理的几种方式
编程界明世隐的博客
12-17 3728
Springboot跨域处理的几种方式 allowedOrigins CrossOrigin
谷歌浏览器跨域处理
shibaweijin的博客
08-01 1158
步骤1： 谷歌浏览器 打开新的标签页，在地址栏输入： chrome://flags/#block-insecure-private-network-requests，直接回车；步骤2 ： 找到 Block insecure private network requests（一般第一项就是），在右侧下拉框中，选择设置为Disabled，重启谷歌浏览器；
vue实战指南 vue项目跨域处理
一个做过前端开发的产品经理，经历过睿智产品的折磨导致脱发之后，励志要翻身"农奴"把歌唱，一边打入敌人内部一边持续提升自己，为我们广大开发同胞谋福祉，坚决抵制睿智产品折磨我们码农兄弟！
10-10 1604
具体来说，当一个请求的发起者和目标资源位于不同的域时，浏览器会阻止该请求。通过本文的介绍，希望能够帮助读者更好地理解和掌握在Vue项目中处理跨域请求的方法。CORS是一种机制，它使用额外的HTTP头来告诉浏览器允许一个域上的网页访问另一个域上的资源。希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。通过设置一个代理服务器，前端请求可以发送到代理服务器，再由代理服务器转发到目标服务器，从而绕过浏览器的同源策略。标签来实现跨域请求的技术。
Servlet允许跨域处理
热门推荐
fay_maplemei的博客
04-12 1万+
使用 CORS协议允许 Response 跨域 /* 允许跨域的主机地址 */ response.setHeader("Access-Control-Allow-Origin", "*"); /* 允许跨域的请求方法GET, POST, HEAD 等 */ response.setHeader("Access-Control-Allow-Methods", "*"); /* 重新预检...
python 跨域处理方式
python学习者的博客
01-15 5492
因为浏览器的同源策略限制，不是同源的脚本不能操作其他源下面的资源，想操作另一个源下面的资源就属于跨域了，这里说的跨域是广义跨域，我们常说的代码中请求跨域，是狭义的跨域，即在脚本代码中向非同源域发送http请求 浏览器的同源策略（SOP/same origin policy）是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到XSS（跨站脚本攻击 cross site script...
9、gateway跨域处理
weixin_43472934的博客
02-21 1225
官方网站：https://docs.spring.io/spring-cloud-gateway/docs/current/reference/html/#cors-configuration 测试跨域 第一步：在gateway添加user.html <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title>
thinkphp 跨域处理
OnTheway
08-23 1451
thinkphp6 跨域的一个非正常处理方式 入口文件加header，就可以了 解决了很长一段时间各种尝试。 包括但不限于下列 thinkphp中间件处理，自定义中间件处理。 nginx处理等等 最后看到参考文章的第一种方法直接就行了，当时就很感动，感谢作者，内容大家自行前往查看。 参考文章 thinkphp5 关于跨域的一些坑，附上解决办法（比较全面了） - 一个网名 - 博客园 (cnblogs.com) ...
magento2跨域处理包
12-06
为了解决这个问题，Magento 2 提供了跨域处理包，使开发者能够配置并允许来自其他域的请求。 **跨域资源共享（CORS）基础** 跨域资源共享是一种机制，它使用额外的HTTP头来告诉浏览器允许一个域上的网页访问另一个...
9种类前端接口跨域处理方案
01-08
除了JSONP和CORS，还存在其他多种跨域处理技术，例如： 1. 使用代理服务器：在与浏览器同源的服务器上设置代理，将请求转发给目标服务器，并将响应返回给浏览器。 2. 使用window.name实现跨域：利用window.name在...
关于python 跨域处理方式详解
09-17
Python跨域处理主要涉及到Web开发中的同源策略（Same-Origin Policy），这是浏览器实施的一种安全机制，旨在防止恶意脚本从不同源获取敏感信息。当一个Web应用试图通过HTTP请求访问不同源的资源时，浏览器会根据同源...
Java和数据库的关系
最新发布
LiLiYuan.的博客
08-23 157
一个只会写Java代码但不懂数据库的工程师，就像一个物流调度员不知道仓库的容量、货架规则、叉车性能一样，他发出的指令很可能效率低下，甚至导致仓库瘫痪（数据库瓶颈）。数据库（MySQL, Oracle等） 就像一个专业的仓库，它有自己的管理体系、安保措施（权限）、货物摆放规则（索引）和进出流程（事务）。数据库本身是一个独立的、巨大的知识领域，但“数据库的使用、优化和深度理解”绝对是Java后端工程师进阶的核心组成部分。Java后端程序 就像是操作这个仓库的整个物流系统，包括下单、调度、打包、运输等。
项目1总结其一
m0_74968370的博客
08-20 318
本文介绍了F1经理模拟系统的数据库和后台设计要点。数据库设计遵循三大范式：1NF（列不可分）、2NF（非主键完全依赖主键）、3NF（非主键直接依赖主键），并设计了9张表实现逻辑闭环。系统采用SpringBoot框架，包含17个关键依赖包，如MyBatis、JWT、Redis等。后端设计了统一返回结果类Result处理响应数据，并自定义了F1Exception异常类。整体设计注重规范化、扩展性和开发效率，为F1经理模拟系统奠定坚实基础。
用通义灵码渐进式开发 0-＞1 实现高考志愿规划项目题文档
阿里巴巴云原生的博客
08-22 926
渐进式开发：从页面设计 → 前端实现（设计稿还原） → 后端实现（核心调用） → 功能优化（数据持久化），分阶段实现复杂需求。上下文记忆：通义灵码自动关联前序对话中的变量和功能，无需重复说明。版本管理：每轮对话生成代码快照，可随时回退或对比。实时验证：每轮对话后可立即运行测试。按需扩展：用户可选择优先实现最关心的功能。通过这种分步引导的方式，即使没有编程经验的用户也能通过自然语言交互逐步构建完整项目。
【Web后端】Django、flask及其场景——以构建系统原型为例
qq_45418349的博客
08-16 827
Django 是一个高级 Python Web 框架，提供了完整的“开箱即用”功能，包括 ORM、认证、管理后台等，便于快速开发安全且可维护的网站。Flask 是一个轻量级 Python Web 框架，核心功能比较简单，但扩展性chao强，适合小型项目或需要高度定制化的场景。
DataAnalytics之Tool：Metabase的简介、安装和使用方法、案例应用之详细攻略
头部AI社区如有邀博主AI主题演讲请私信—心比天高，仗剑走天涯，保持热爱，奔赴向梦想！低调，专注，谦虚，自律，反思，成长，还算比较正能量的博主，公益免费传播…内心特别想在AI界做出一些可以推进历史进程影响力的技术(兴趣使然，有点小情怀，也有点使命感呀
08-19 1384
​ DataAnalytics之Tool：Metabase的简介、安装和使用方法、案例应用之详细攻略 目录 Metabase的简介 Metabase的安装和使用方法 Metabase的案例应用 Metabase的简介 Metabase 是一个易于使用的开源商业智能和嵌入式分析工具，旨在让公司中的每个人都可以提问并从数据中学习。Metabase是一个开源的数据分析工具，允许用户通过简单的界面查询数据，而不需要SQL知识。它支持多种数据库，有云版和自托管选项，还有丰富的功能如仪表盘、模
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值