在pikachu靶场的 csrf（token）关卡中，存在一个同源策略的机制，目前还没有复现成功，在网上也看了看其他博主关于本关卡的复现过程，主要有两种方法：
1.在恶意网页中先进行网页的请求，通过js 代码提取 token ，
2.使用 bp 专业版的插件，实现自动提取 token 的目标。

但是上面两种方式存在一个问题就是，恶意网页需要上传到用户主机中，如果在 kali 的服务器上，会因为同源策略无法获取token数据。而使用 bp 专业版的话，需要能够监听用户主机的网络数据包。

今天主要介绍一下同源策略的概念。

先搞懂：什么是同源策略？一句话说清核心

同源策略，简单来说就是：浏览器规定，只有“同源”的网页，才能相互访问对方的资源（比如Cookie、LocalStorage、DOM、接口数据等）；如果“不同源”，就会被浏览器拦截，禁止相互访问。

这里的关键是“同源”——什么才算“同源”？必须同时满足以下3个条件，缺一不可：

1. 协议相同：比如都是http、https，不能一个是http，一个是https；

2. 域名相同：比如都是www.baidu.com，不能一个是www.baidu.com，一个是blog.baidu.com（子域名不同也不算同源）；

3. 端口相同：比如都是80端口（http默认端口）、443端口（https默认端口），不能一个是8080，一个是80。

举几个直观的例子，帮大家快速判断“是否同源”（以 https://www.example.com:443 为基准）：

目标地址	是否同源	原因
https://www.example.com:443/index.html	是	协议、域名、端口完全相同
http://www.example.com:443/index.html	否	协议不同（http vs https）
https://blog.example.com:443/index.html	否	域名不同（子域名blog vs www）
https://www.example.com:8080/index.html	否	端口不同（8080 vs 443）
https://www.example.org:443/index.html	否	主域名不同（example.org vs example.com）
这里有个容易踩的小细节：端口号的默认值——http协议默认端口是80，https默认是443，如果你在URL中不写端口，浏览器会自动补充默认端口。比如 https://www.example.com 和 https://www.example.com:443 是同源的，而 http://www.example.com:8080 和 http://www.example.com 就不是同源（端口8080 vs 80）。

核心灵魂：为什么需要同源策略？保护你的数据安全

很多同学会觉得，同源策略“多此一举”，反而给开发带来了跨域的麻烦。但其实，同源策略是浏览器最核心的安全机制之一，没有它，你的账号、密码、个人信息会变得极度危险。

我们用一个真实的场景，带你理解同源策略的作用：

假设你登录了某银行网站（https://www.bank.com），此时浏览器会保存银行网站的Cookie（里面包含你的登录凭证，比如SessionID）。如果你没有关闭浏览器，又打开了一个恶意网站（https://www.evil.com）。

如果没有同源策略，这个恶意网站就可以通过JavaScript代码，直接访问你银行网站的Cookie、LocalStorage，甚至操作银行网站的DOM（比如自动点击转账按钮）——相当于恶意网站能直接“冒充你”，操作你的银行账户，后果不堪设想。

而有了同源策略，浏览器会拦截恶意网站的请求：因为 www.evil.com 和 www.bank.com 不同源，所以恶意网站无法访问银行网站的任何资源，也无法操作其DOM，从而保护了你的账号安全。

总结一下：同源策略的核心目的，是防止“跨域恶意网站”窃取其他网站的敏感数据，避免用户信息泄露和恶意操作。它就像一道“安全防火墙”，把不同来源的网站隔离开，确保各自的资源安全。

重点拆解：同源策略限制了什么？3类核心资源

同源策略并不是“一刀切”地禁止所有跨域操作，而是有针对性地限制了3类核心资源的访问，我们逐一拆解，帮大家分清“能做什么”“不能做什么”。

1. 限制DOM访问：不同源网页，不能操作彼此的DOM

比如，你在www.a.com的网页中，嵌入了一个iframe，iframe的地址是www.b.com。因为两者不同源，所以www.a.com的JavaScript代码，无法操作iframe（www.b.com）里面的DOM（比如获取iframe中的文本、修改按钮内容）；反之，iframe里的代码也无法操作父页面的DOM。

这个限制的目的很明确：防止恶意网站通过iframe嵌入合法网站，然后操作其DOM，诱导用户进行错误操作（比如伪装登录按钮，窃取账号密码）。

2. 限制数据访问：不同源网页，不能读取彼此的敏感数据

这是同源策略最核心的限制，主要包括以下几类数据：

• Cookie、LocalStorage、SessionStorage：这些是浏览器存储用户数据的核心方式，不同源的网页无法读取彼此的这些数据；

• IndexedDB、Web SQL：浏览器的本地数据库，同样受同源策略限制，不同源无法访问；

• 接口返回的数据：这是前端开发中最常遇到的限制——不同源的网页，通过AJAX、Fetch请求对方的接口，会被浏览器拦截，无法获取返回数据（这就是我们常说的“跨域请求失败”）。

这里有个小例外：Cookie的特殊性——Cookie的同源判断，除了协议、域名、端口，还会受“Domain”和“Path”属性影响。比如，如果你给Cookie设置了Domain为“.example.com”，那么子域名（blog.example.com、www.example.com）都能访问这个Cookie（前提是协议、端口相同）。

3. 限制网络请求：不同源的网络请求，需满足额外条件

除了AJAX、Fetch请求，浏览器对其他跨域网络请求也有限制，比如：

• WebSocket：WebSocket不受同源策略限制，可以跨域建立连接，但需要服务器端允许；

• Script、Link、Img标签：这些标签的跨域加载是允许的（比如你在自己的网站上引用百度的图片、CDN的JS文件），但无法读取这些资源的内容（比如无法通过JS获取Img标签加载的图片的像素数据）。

这里要注意：“允许加载”和“允许读取内容”是两回事——比如你可以在www.a.com引用www.b.com的JS文件，JS文件会正常执行，但www.a.com的代码无法读取这个JS文件的源码内容。

实战必备：常见跨域场景+解决方案（新手直接用）

理解了同源策略，最核心的需求就是“解决跨域问题”——毕竟实际开发中，我们经常需要在前端页面请求不同源的接口（比如前端项目部署在localhost:8080，后端接口部署在localhost:3000，这就属于不同源）。

下面分享4种最常用的跨域解决方案，从“前端单独解决”到“前后端配合”，覆盖不同开发场景，新手可以直接套用。

方案1：CORS（跨域资源共享）——最推荐、最标准的方案

CORS（Cross-Origin Resource Sharing）是W3C标准，也是目前最主流的跨域解决方案。它的核心思路是：后端在响应头中添加允许跨域的配置，告诉浏览器“这个接口允许哪些域名访问”，浏览器收到后，就会放行跨域请求。

核心配置（后端实现，以Node.js为例）

// Node.js + Express 示例
const express = require('express');
const app = express();

// 允许所有域名跨域（开发环境可用，生产环境不推荐）
app.use((req, res, next) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  // 允许的请求方法
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  // 允许的请求头
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  // 允许携带Cookie（如果需要跨域传递Cookie，必须设置这个）
  res.setHeader('Access-Control-Allow-Credentials', 'true');
  next();
});

// 接口示例
app.get('/api/data', (req, res) => {
  res.send({ code: 200, data: '跨域请求成功！' });
});

app.listen(3000, () => {
  console.log('服务器运行在3000端口');
});

关键说明

• Access-Control-Allow-Origin：指定允许跨域的域名，比如 ‘https://www.example.com’，* 表示允许所有域名（生产环境不推荐，存在安全风险）；

• Access-Control-Allow-Credentials：如果需要跨域传递Cookie，必须设置为true，同时前端请求时也要设置withCredentials: true；

• 适用场景：前后端分离项目，后端可以修改代码（最常用的场景）。

方案2：代理服务器——前端单独就能解决的方案

如果后端无法修改代码（比如调用第三方接口），前端可以通过“代理服务器”解决跨域问题。核心思路是：前端请求自己的代理服务器，代理服务器再请求目标接口（服务器之间的请求不受同源策略限制），然后将结果返回给前端。

常用实现方式（以Vue CLI为例）

在Vue项目的vue.config.js中配置代理：

module.exports = {
  devServer: {
    proxy: {
      // 匹配所有以 /api 开头的请求
      '/api': {
        target: 'https://www.target.com', // 目标接口域名
        changeOrigin: true, // 开启代理，模拟同源请求
        pathRewrite: {
          '^/api': '' // 重写路径，去掉 /api 前缀（如果目标接口没有/api前缀）
        }
      }
    }
  }
};

关键说明

• changeOrigin: true：必须开启，让代理服务器模拟同源请求，避免目标服务器拒绝；

• pathRewrite：如果前端请求的路径和目标接口路径不一致，需要重写路径；

• 适用场景：前端开发环境，后端无法修改代码，或调用第三方接口。

方案3：document.domain——仅限主域名相同的子域名跨域

如果两个网页的主域名相同，只是子域名不同（比如 www.example.com 和 blog.example.com），可以通过设置 document.domain 来实现跨域访问。

实现方式（两个页面都需要设置）

// www.example.com 页面
document.domain = 'example.com';

// blog.example.com 页面
document.domain = 'example.com';

// 此时，两个页面就可以相互访问DOM和Cookie了

关键说明

• 仅限主域名相同的子域名之间跨域，无法用于主域名不同的场景；

• 需要两个页面都手动设置document.domain，否则无法生效；

• 适用场景：同一主域名下的子域名之间的跨域（比如公司内部的不同子系统）。

新手避坑：4个常见误区，别踩！

误区1：跨域请求失败，一定是前端的问题

错！跨域问题的核心是“浏览器的同源策略拦截”，但解决问题的关键往往在后端。比如CORS配置、接口允许跨域，都是需要后端来实现的；前端的代理方案，只是“绕开”了浏览器的拦截，本质还是需要服务器之间的请求支持。

误区2：CORS配置了Access-Control-Allow-Origin: *，就一定能跨域成功

不一定！如果前端请求需要携带Cookie（比如登录态），那么Access-Control-Allow-Origin不能设为*，必须指定具体的域名，同时还要设置Access-Control-Allow-Credentials: true，否则浏览器会拒绝放行。

误区3：Script、Img标签能跨域加载，AJAX也能直接跨域请求

错！Script、Img标签的跨域加载，是“浏览器允许加载资源，但不允许读取资源内容”；而AJAX请求是“需要读取接口返回的数据”，所以会被同源策略拦截。两者的限制逻辑不同，不能混为一谈。

误区4：同源策略只限制前端，服务器之间的请求不受限制

对！同源策略是浏览器的安全机制，只作用于浏览器端。服务器之间的请求（比如后端接口调用第三方接口），不受同源策略限制，所以代理服务器方案才能生效——本质就是“前端请求代理服务器（同源），代理服务器请求目标接口（服务器之间无限制）”。

面试高频：3道同源策略经典题（附答案）

同源策略是前端面试的高频考点，这里整理3道最常考的题目，帮大家提前准备，面试不慌～

题目1：什么是同源策略？同源的判断条件是什么？

答案：同源策略是浏览器的安全机制，规定只有同源的网页才能相互访问对方的资源，不同源则会被拦截。同源需同时满足3个条件：协议相同、域名相同、端口相同。

题目2：同源策略限制了哪些操作？

答案：主要限制3类操作：1. 限制不同源网页操作彼此的DOM；2. 限制读取不同源网页的敏感数据（Cookie、LocalStorage、接口数据等）；3. 限制不同源的网络请求（AJAX、Fetch等）。

题目3：常用的跨域解决方案有哪些？分别适用什么场景？

答案：4种常用方案：

• CORS：最推荐，前后端配合，适用前后端分离项目；

• 代理服务器：前端单独解决，适用后端无法修改代码或调用第三方接口；

• JSONP：兼容旧浏览器，仅支持GET请求；

• document.domain：仅限主域名相同的子域名跨域。

最后：为什么要吃透同源策略？不止是解决跨域

很多新手会觉得，“只要会用CORS、会配代理，就能解决跨域问题，没必要深入理解同源策略”。但其实，吃透同源策略，对前端开发的意义远不止于此。

1. 建立安全思维：理解同源策略的底层逻辑，能帮你识别前端开发中的安全风险（比如XSS、CSRF攻击），写出更安全的代码；

2. 高效解决问题：遇到跨域问题时，能快速定位原因（是后端CORS配置问题，还是前端请求方式问题），而不是盲目百度；

3. 应对面试：同源策略是前端面试的基础考点，深入理解能让你在面试中脱颖而出，体现你的技术深度。

总结

同源策略，本质是浏览器的“安全卫士”，核心是“限制不同源网页的资源访问”，保护用户数据安全。

记住3个核心点：

1. 同源判断：协议、域名、端口三者完全相同；

2. 核心限制：DOM访问、数据读取、网络请求；

3. 解决方案：CORS（优先）、代理服务器、JSONP、document.domain（按需选择）。

觉得有用的话，别忘了点赞+转发，帮更多前端新手避开跨域的坑～ 😊