跨域漏洞，我把前端线上搞崩溃了

最近迁移前端资源到云厂商时，我遇到了一个奇怪的问题 —— 线上环境某个 CSS 资源跨域了，后果直接导致项目崩溃不可用。大领导直接找到了我的工位，激动的心，颤抖的手，问题原因就是找不到！！！

很奇怪，我已经提前设置了资源允许跨域访问，提测环境、测试环境也已经正常运行很久了，理论上不应该出现跨域问题。而且更奇怪的是，这个问题只出现在某个 CSS 文件上。

建议大家在阅读本文时结合目录一起查看。本文详细介绍了从跨域问题发现到跨域问题解决的整个过程，文章还简要提到了前端资源链路。结合上下文来看，对处理前端跨域问题具有一定的参考价值。希望对大家有所帮助。

什么是跨域问题？

跨域及其触发条件

跨域是指在 web 开发中，一个网页的源（origin）与另一个网页的源不同，即它们的协议、域名或端口至少有一个不同。跨域问题是由于浏览器的同源策略而产生的，它限制了一个网页中加载的资源只能来自同一个源，以防止恶意网站在未经允许的情况下访问其他网站的数据。

以下情况会触发跨域问题：

1. 不同域名：当页面的域名与请求的资源的域名不一致时，会触发跨域问题，如从 example.com 页面请求资源来自 api.example.net。
2. 不同协议：如果页面使用了 https 协议加载，但试图请求非 https 资源，也会触发跨域问题。
3. 不同端口：如果页面加载的是 example.com:3000，但试图请求资源来自 example.com:4000，同样会触发跨域问题。
4. 不同子域名：即使是不同的子域名也会被认为是不同的源。例如，subdomain1.example.com 和 subdomain2.example.com 是不同的源。

跨域问题会影响到浏览器执行以下操作：

• JavaScript的XMLHttpRequest或Fetch API请求其他源的资源。
• 通过<img>、<link>、<script>等标签加载其他源的资源。
• 使用CORS（跨源资源共享）机制实现跨域数据传输。

解决跨域的方法

解决跨域问题的方法有多种，具体的选择取决于你的应用场景。以下是一些常见的跨域解决方法：

1. 跨域资源共享（CORS） ：CORS是一种标准机制，通过在服务器端设置响应头来允许或拒绝跨域请求。这是解决跨域问题的最常见方法。
   • 在服务器端设置响应头中的Access-Control-Allow-Origin字段来指定允许访问的域名或使用通配符*表示允许所有域名访问。
   • 其他相关的CORS头，如Access-Control-Allow-Methods和Access-Control-Allow-Headers，用于控制允许的HTTP方法和请求头。
2. JSONP（JSON with Padding）： 通过动态创建 <script> 标签来实现跨域请求的技术。服务器端返回的数据被包装在一个函数调用中，该函数名由客户端指定。虽然 JSONP 简单易用，但只支持GET请求，由于安全性较差（容易受到跨站脚本攻击），存在安全风险。

   // 客户端代码
   function handleResponse(data) {
     console.log('Received data:', data);
   }
   
   const script = document.createElement('script');
   script.src = 'https://example.com/api/data?callback=handleResponse';
   document.head.appendChild(script);
   

3. 代理服务器：设置一个位于同一域的代理服务器，将跨域请求代理到目标服务器，并将响应返回给客户端。这个方法需要服务器端的额外配置。
4. 跨文档消息传递： 使用window.postMessage()方法，可以在不同窗口或iframe之间进行跨域通信。
5. WebSocket： WebSocket是一种双向通信协议，不受同源策略的限制。通过WebSocket，客户端和服务器可以建立持久连接进行跨域通信。
6. Nginx反向代理： 使用 Nginx 或其他反向代理服务器可以将跨域请求转发到目标服务器，同时解决跨域问题。这种方法适用于前端无法直接控制目标服务器的情况。

每种方法都有其适用的场景和安全考虑，具体的选择取决于项目的需求和架构。

背景与跨域设置

项目背景介绍

最近我负责了一个前端迁移第三方云（阿里云）的工作，由于这是一个多项目组合成的微前端项目，我考虑在前端迁移中，尽可能统一各个应用项目流程、规范和技术。一是形成统一的规范和方式，二是团队项目各负责人按照方案迁移各自项目时避免因各自不一致导致出现问题。

而在这其中就存在着资源存储和加载不一致的情况，我遇到了三种不同的方法：

1. 直接使用云存储提供的资源地址

   这是一种常见方式，但也伴随着一些潜在问题。首先，访问云资源可能会有一定的延迟，尤其对于大型文件或数据集。其次，公共云资源地址可能存在安全性和隐私风险，特别是涉及敏感信息时。此外，直接使用OSS资源地址可能导致资源管理分散，难以跟踪和监控资源的使用情况，也可能限制了一些高级功能的实现，如CDN缓存控制、分布式访问控制以及资源日志记录。

   https://company.oss-cn-beijing-internal.company.com/productdata/gateway/prod/assets/index-a12abcbf.css
   

2. 使用配置了云存储的CDN域名地址

   这种方式是我比较推荐的方式，然而团队在配置这块链路上存在一些潜在问题。首先 CDN 请求打到了团队内部的一个老服务器，目前老服务器的稳定性不如预期，稳定性方面较差，出现过故障，影响用户体验。前端迁移到第三方云的主要目的之一就是解耦该服务，提供更稳定的前端资源环境。此外，该服务器与其他服务器存在依赖关系，增加了项目的复杂性和不稳定性，解耦是必要的。并且使用这个 CDN 的项目很多，随着时间推移，项目的增加可能会使得该资源地址的维护变得相当复杂。

   https://static.company.com/productdata/gateway/prod/assets/index-a12abcbf.css
   

3. 直接加载服务器内部的前端资源

   直接加载服务器内部的前端资源是通过网站域名的代理访问服务器内部资源的一种方法。有几个项目使用这个种方式，这种方式具备简单、快捷等优势。然而，这种方式可能引入网络延迟和性能影响，因为资源请求需要经过团队内部的服务器。同时，存在单点故障的风险，如果内部服务器发生故障或不可用，将导致网站前端资源无法加载，可能对用户造成不便。它也依赖于团队内部的网络环境，需要保持网络的稳定性和可靠性以确保资源能够顺利加载。

为了统一这三种方式并规避潜在问题，我想到了一个综合性的前端资源请求链路方案。通过将 OSS 存储桶、CDN 和网关服务器相互结合，以提升资源分发速度和安全性，同时减轻 OSS 服务器的负载。此外，我还将所有资源引用集中到一个配置文件中，位于网关服务器，以便轻松进行维护和跟踪。（这里只是简要介绍，我将在后续文章分享详细细节）

然而，在初步方案制定后，也需要考虑如何处理在同源策略下可能出现的跨域问题。

前端静态资源跨域设置

我在OSS存储桶的跨域设置中配置了允许跨域头，使得网页可以通过浏览器访问OSS资源，免受同源策略的限制。

为什么我会选择在 OSS 存储桶配置呢？

主要因为这个存储桶非常整洁，只有两个项目在使用，已经提前简单配置了跨域处理。而且这两个项目后续会按照前端迁移方案进行统一迁移处理，因此我认为直接在 OSS 存储桶配置跨域会更为简洁和可维护，我还和 SRE 老师调整了一下配置（然而，没想到恰恰因为我的这个行为，导致后面出现了跨域问题）。

此外，为了确保安全性，我采取了以下措施：

• 将项目单独、分批迁移到阿里云 OSS。
• 在网关服务器中使用nginx进行项目正则匹配，每次迁移就开放一个项目。 location ~ ^/(gateway|message)/prod/
• 项目在提测、测试环境都各自运行一段时间（有的甚至在1～2个月）。
• 在未迁移到正式环境前，各项目按照各自排期计划进行过多次发版。

这些措施是为了确保有问题，可以在提测环境、测试环境中暴露出来。然而，在迁移第3个项目到正式服环境时，出现了问题。。。

奇怪的CSS资源跨域问题

为什么只有某个CSS文件受影响？

跨域问题通常由浏览器的同源策略引起，该策略限制了来自不同源的资源之间的交互。

如果资源有跨域问题，不应该只有某个CSS文件出现跨域问题呀？

分析后，我发现浏览器中 CSS 资源的返回头中缺少 CORS 头信息，截图如下：

正常情况下，应该是下图这样：

这时候我在想不应该呀，我已经在源站 OSS 存储桶配置了允许跨域头，这里的返回头中应用是要携带的，而且别的文件（如html、js）返回头中都是携带了允许跨域，但是为什么只有这个 CSS 资源的就没有呢？

需要注意的是，通常情况下，HTML 文件本身不受同源策略的限制，因此可以从不同源加载 CSS 文件。但如果 CSS 文件中包含引用其他跨域资源（如字体、图片等），那么同源策略仍然会生效，需要特别注意处理这些跨域资源的加载。

问题的深层原因分析

排除了自身导致的问题

面对这样一个看似简单的跨域问题，我做了一系列的排查和解决过程。首先，我排除了浏览器缓存、资源代码方面以及浏览器本身的问题，并同 SRE 老师否定了前端资源链路（如OSS、CDN）配置错误的可能性。随后，我们还仔细查看了网关日志，但未能发现问题。

一直没找到导致跨域问题出现的原因，我们也想到了直接在网关服务器或 CDN 中强制加入允许跨域头。然而我们一讨论，发现不行，因为 OSS 中已经配置了跨域，强制加入允许跨域头，会出现双重跨域问题；如果移除 OSS 中跨域头也不行，因为已经有两个项目已经直接引用阿里云地址，移除后那两个项目也会出现跨域问题。

寻求阿里云 CDN 运维工程师的帮助

结合我们自己的分析，我们认为是前端资源请求链路的哪个环节出现了问题，但是迟迟找不到原因，于是我们咨询了阿里云 CDN 运维工程师，因为阿里云 CDN 的日志隔天才出来，所以借此希望通过阿里云 CDN 运维老师能够查看下当天的 CDN 日志，从而找到问题。查看日志后，阿里云 CDN 运维老师也只是给出了日志显示一切正常，但随后我们继续沟通。

随后，给到了我们一个关键点：“OSS要能响应跨域头，请求头必须携带 Origin 请求头”。阿里云 CDN 运维老师也说传任何值都可以，但是我多次查看到浏览器请求已经携带了 Origin 请求头。如下图：

这就奇怪了！此时测试环境和提测环境又无法复现 CORS 跨域问题，我们又不能直接在生产环境调试这个问题。

借助工具复现问题

于是我在思考是否能够在提测环境模拟出加载有问题资源的场景。我想到了可以通过拦截浏览器对提测环境的资源请求地址，并将其代理到具有问题的资源地址上来实现这个目的。为了实现这一方案，我使用了一个名为 GoRes 的谷歌浏览器插件。

成功复现，见下图：

随后，在多次代理调试中，我发现只有在正式服这个项目的资源地址中出现了这个问题。我和 SRE 老师一起再次确认了提测环境、测试环境和正式环境中各自网关服务器和 CDN 域名等的差异性，当然还是没发现问题！

问题逐渐浮现出水面

经过综合分析，我们怀疑 CDN 缓存可能是导致问题的原因。然而，我们无法直接查看缓存的资源，只能再次联系阿里云 CDN 的运维老师。经过多次沟通，我们得知如果客户端在第一次请求 CDN 时没有携带 Origin 请求头，CDN 就不会将 Origin 请求头传递到 OSS，OSS 因此不会响应跨域头，而后续 CDN 便会将没有跨域头的资源内容缓存下来。

这时我才意识到，OSS 内部存在着对 Origin 辨别的跨域处理机制。而在此之前，上传代码资源到 OSS 后，由于是正式环境，为了安全起见测试资源是否上传成功，我直接在浏览器中访问了一个 CSS 文件地址（当时请求到了资源，我还信心满满，丝毫没有注意到还有这么一个坑），但这一步的操作却间接成为了导致跨域问题出现的导火索。

通常情况下，当网页加载跨域资源时，由于违反了同源策略，浏览器会自动添加源 Origin 到资源的请求头中。然而，由于我直接请求了 CSS 资源地址，未触发同源策略，浏览器也就没有自动添加 Origin 请求头，导致请求到的 OSS 资源中没有跨域头配置。这也就是为什么 CDN 缓存了没有跨域头的资源。

在网页加载资源时，由于 CDN 缓存了没有跨域头的资源，无论你如何请求，只要 CDN 缓存一直存在，浏览器加载的就是没有跨域头的资源。 因此，这也导致了资源跨域问题的出现。

本来是为了谨慎一点，提前验证资源是否已上传成功的操作，没想到却成为了跨域问题出现的导火索！！！

这个问题的教训很深刻，让我们意识到必须在向 OSS 请求资源时强制添加 Origin 请求头，以确保今后前端资源的稳定性。否则，这个问题将成为一个定时炸弹。我们决定在网关服务器上分工合作解决这个问题，以杜绝类似情况再次发生。这个经验教训也提醒了我和SRE老师要更加谨慎地处理类似操作，以避免潜在的问题。

如何稳定解决跨域问题

尽管我们已经找到了问题的根源，但是不排除是不是还有其他类似问题，为了保险起见，我决定还是缩小影响范围。在确保测试无问题后，逐步放开所有项目。

SRE 老师负责处理向 OSS 传递Origin请求头的部分，而我负责处理 Nginx location 的正则匹配项目的部分。以下是我们的网关服务器配置：

location ~ ^/(message|dygateway|logcenter)/tice/ { 
    set $cors_origin "";
    if ($http_origin = "" ) {
        set $cors_origin 'static.example.com';
    }
    if ($http_origin != "") {
        set $cors_origin $http_origin;
    }
    proxy_set_header Origin $cors_origin;
}

• location ~ ^/(message|dygateway)/tice/：这是一个正则匹配，能更容易地添加或移除项目。

• proxy_set_header Origin $cors_origin;：如果请求中包含 Origin 头部，它会被直接传递给 OSS；如果没有，它会被设置为一个值后再传递给 OSS。

配置完成后，直接在浏览器中请求下面这个资源地址，你会发现请求头并没有添加上去。这并不是配置出错，而是因为上面我们提到的CDN不仅缓存了资源，还缓存了请求头。

https://static.company.com/productdata/gateway-admin/prod/assets/index-a12abcbf.css

所以我们在这个资源的地址后面拼接了参数，相当于是请求新的 CDN 资源地址，此时可以发现跨域头已经添加上了。

https://static.company.com/productdata/gateway-admin/prod/assets/index-a12abcbf.css?abc=111

接下来就是在真实项目中测试，首先在 CDN 后台刷新了有问题的项目资源文件目录，清除掉有跨域问题 CDN 资源缓存后。然后重新刷新浏览器，此时这个文件就成功加上了跨域的请求头，页面访问也正常了。

后面我又测试了多次，跨域问题彻底解决。为了避免以后出现类型的问题，所以我又整理了跨域资源共享（CORS）方案，希望对大家有用，请大家接着往下看。

跨域资源共享方案

跨域资源共享方案是解决前端资源跨域问题的最常见方法，可维护性强，配置简单，可以说这是业界普遍处理前端资源跨域的方式。下面我们将深入探讨三种不同的 CORS 配置方案，并分析各自的优缺点。

OSS存储桶配置跨域

我们都知道 OSS（对象存储服务）是阿里云提供的海量、安全、低成本、高可靠的云存储服务。但其实 OSS 也能设置跨域处理，可以让客户端前端应用从其他域名请求资源。

实施步骤：

1. 登录阿里云控制台，找到对应的OSS存储桶。
2. 进入存储桶的管理界面，选择“跨域设置”。
3. 添加CORS规则，指定允许的来源、方法、头信息等。

优点：

• 简单易用：配置简单，通过图形界面即可完成。
• 安全性高：可以灵活控制允许访问的来源，减少安全风险。

缺点：

• 依赖云服务商：此方法只适用于使用阿里云OSS的情况，不适用于其他云服务商或自建服务器。

注意：OSS存储桶配置完成跨域后，需要在请求 OSS 存储桶资源时，在请求头中配置 Origin。因为 OSS 内部的机制是 OSS 响应跨域头的前提是必须要携带源站Origin请求头。 建议大家强制配置必传 Origin 请求头，否则容易出现我这次的问题。使用OSS存储桶配置跨域制定方案时，可以参考我在上面的处理：“如何稳定解决跨域问题”。

网关服务器配置跨域

在网关服务器配置跨域，网关服务器通常配置了 Nginx 反向代理服务器。通过配置 Nginx location，可以实现对特定域名的允许跨域支持。

实施步骤：

1. 修改nginx配置文件（通常位于/etc/nginx/nginx.conf），添加CORS相关配置。
2. 配置Access-Control-Allow-Origin、Access-Control-Allow-Methods、Access-Control-Allow-Headers等头信息。

location / {
    add_header 'Access-Control-Allow-Origin' '*';
    add_header 'Access-Control-Allow-Methods' 'GET,POST,OPTIONS,PUT,DELETE';
    add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
    add_header 'Access-Control-Expose-Headers' 'Content-Length,Content-Range';
}

优点：

• 灵活性高：可以自由配置适应特定需求。
• 适用性广：适用于各种服务器环境，不依赖特定云服务商。

缺点：

• 配置复杂：需要熟悉nginx配置。

CDN配置跨域

CDN（内容分发网络）是一种通过将内容缓存到全球各地节点，加速用户访问速度的网络服务。但也能通过 CDN 配置 CORS，可以在边缘节点处实现跨域。

实施步骤：

1. 登录CDN服务提供商的控制台，找到相应CDN加速域名。
2. 进入域名配置界面，找到CORS配置选项。
3. 添加CORS规则，指定允许的来源、方法、头信息等。

优点：

• 高性能：CDN 服务通常提供全球分发，可以加速跨域请求，提供更好的性能。
• 规模化：适用于大规模的Web应用，可支持高并发的跨域请求。

缺点：

• 成本：使用 CDN 服务可能会产生额外的费用，特别是对于大量的数据传输。
• 配置复杂性：相对于 OSS 或 Nginx，CDN 的配置可能会更为复杂，需要在控制台进行详细的设置。

注意：腾讯云 CDN 中有专门针对跨域设置的勾选项，只需要选中保存就行。

三种跨域处理方案各有优缺点，选择合适的方案取决于具体的业务需求和技术栈。我上面所说的也只供大家参考，毕竟 CDN、存储桶这种很大程度受限于云平台，这也是我把允许跨域配置在网关服务器的原因之一。可以综合考虑选择合适的方案或者结合多种方案来实现跨域资源共享。

结语

前端资源加载问题往往受多种因素的影响，包括 CDN 配置、资源请求链路、云存储配置等。因此，需要全面分析并综合考虑可能出现问题的任何风险点。也要合理使用浏览器插件工具、网络抓包工具和服务器日志分析等工具，可以帮助我们更快速地诊断和解决问题。如果问题复杂或涉及云服务配置，与云厂商的支持团队联系可以提供专业的帮助。

这是我关于资源跨域的一篇文章，里面关于定位问题和跨域方案希望对您有所帮助和参考。如果您需要进一步的协助或有任何问题，请随时提问！