第 8 卷

14. 解释同源策略(SOP)及其对Web安全的意义

同源策略（Same-Origin Policy，简称SOP）是浏览器的核心安全策略，用于限制一个源（Origin）的文档或脚本如何与另一个源的资源进行交互。其核心目的是「隔离不同源的资源，防止恶意脚本窃

取、篡改其他源的敏感数据，保护用户隐私和Web应用安全」。

一、同源的定义（三个条件必须同时满足）

两个URL属于「同源」，必须同时满足以下三个条件：

• 协议（Protocol）相同：如都是HTTP或都是HTTPS（http://example.com与

https://example.com不同源）。

• 域名（Domain）相同：如example.com与www.example.com不同源（子域名不同），

example.com与test.com不同源（主域名不同）。

• 端口（Port）相同：如http://example.com:80与http://example.com:8080不同源（默认端口可

省略，HTTP默认80，HTTPS默认443）。

示例：判断http://www.example.com:8080/index.html与以下URL是否同源：

• http://www.example.com:8080/about.html：同源（协议、域名、端口均相同）。
• https://www.example.com:8080/index.html：不同源（协议不同）。
• http://example.com:8080/index.html：不同源（域名不同，无www子域名）。
• http://www.example.com/index.html：不同源（端口不同，默认80 vs 8080）。

二、同源策略的核心限制范围

同源策略主要限制「不同源的脚本对当前源资源的访问」，核心限制包括以下4类：

1. DOM访问限制

• 不同源的脚本无法访问当前源页面的DOM元素，如通过iframe嵌入的不同源页面，父页面无法获取

子页面的DOM，子页面也无法获取父页面的DOM。

• 示例：攻击者在恶意网站中嵌入银行网站的iframe，由于同源策略限制，恶意脚本无法获取iframe

中银行页面的DOM（如用户名、密码输入框内容）。

1. 数据存储访问限制

• 不同源的脚本无法访问当前源的本地存储数据，包括Cookie、localStorage、sessionStorage、

IndexedDB等。

• 示例：恶意网站的脚本无法读取用户访问银行网站时存储在localStorage中的用户信息，也无法获

取银行网站的Cookie。

• 不同源的脚本无法向当前源发起AJAX/Fetch请求（跨域请求），浏览器会拦截该请求，返回CORS

• 示例：前端项目部署在http://frontend.com，无法直接通过AJAX请求http://backend.com的接口

（不同源），需后端配置CORS规则放行。

1. 其他资源访问限制

• 不同源的脚本无法访问当前源的Canvas图像数据、Audio/Video资源等敏感资源，防止信息泄露。

三、同源策略的例外情况（允许跨源访问的资源）

同源策略并非禁止所有跨源资源访问，以下资源的加载不受同源策略限制（但脚本无法直接获取其内容）：

• 图片资源（<img>标签）：如加载不同源的图片（用于图片展示、统计像素等）。
• 脚本资源（<script>标签）：如加载CDN上的JS文件（可能存在JSONP跨域方案）。
• 样式表资源（<link>标签）：如加载不同源的CSS文件。
• 视频/音频资源（<video>/<audio>标签）。
• iframe嵌入的不同源页面（但无法访问其DOM）。

四、同源策略对Web安全的核心意义

同源策略是Web安全的「基石」，没有同源策略，Web应用将毫无安全可言，其核心意义体现在以下3 点：

• 防止敏感数据泄露：限制不同源脚本访问当前源的DOM、Cookie、localStorage等数据，避免攻

击者通过恶意脚本窃取用户的账号密码、个人信息、交易记录等敏感数据。

• 防止恶意篡改资源：限制不同源脚本修改当前源的DOM和数据，避免攻击者通过恶意脚本篡改网站

内容（如植入广告、恶意链接）、修改用户数据（如转账金额、收货地址）。

• 隔离不同Web应用：将不同源的Web应用隔离开来，每个应用的资源和数据独立，即使一个应用被

攻击，也不会影响其他应用的安全（如用户同时打开银行网站和恶意网站，恶意网站无法影响银行网站）。

• 注意：同源策略仅限制「脚本的跨源访问」，无法防御所有安全漏洞（如XSS、CSRF），需配合其

他安全措施（如输入过滤、CSRF Token）共同保障Web安全。

15. 描述前端加密的应用场景和限制

前端加密是指在浏览器端（客户端）对数据进行加密处理后再传输或存储的安全手段，其核心目的是「提升数据在传输或本地存储过程中的安全性」。但前端加密受限于浏览器环境和客户端可控性，无

1. 敏感数据传输加密（核心场景）

• 场景描述：对用户输入的敏感数据（如账号密码、身份证号、银行卡号），在前端加密后再通过网

络传输到后端，即使传输过程中数据被窃听（如HTTP协议下），攻击者获取的也是密文，无法还原为明文。

• 实现方式：

• 密码加密：登录时，前端使用非对称加密（如RSA）对密码加密，后端用私钥解密后验证（避免

密码明文传输）。

• 普通敏感数据：使用对称加密（如AES）加密，密钥由后端通过安全渠道下发（如HTTPS传输的

接口返回）。

• 典型案例：HTTP协议的登录页面（无HTTPS），前端对密码进行RSA加密后提交；金融类网站的

银行卡号输入框，前端加密后传输。

1. 本地存储数据加密

• 场景描述：对需要存储在客户端本地的数据（如localStorage、sessionStorage、IndexedDB中的

用户信息、业务数据）进行加密处理，防止他人通过浏览器开发者工具直接查看或篡改。

• 实现方式：使用对称加密（如AES）对数据加密后存储，解密时需用户输入密钥（如密码）或通过

后端接口获取密钥。

• 典型案例：记住密码功能（加密后存储在localStorage，而非明文）；单页应用（SPA）存储的用

户令牌（Token）加密。

1. 数据脱敏展示与加密传输结合

• 场景描述：对敏感数据先脱敏展示（如银行卡号显示为****1234），同时前端加密完整数据后传输

给后端，兼顾用户体验和数据安全。

• 典型案例：电商网站的收货地址页面，手机号脱敏展示（138****5678），前端提交完整手机号时

加密传输。

1. 前端签名防篡改

• 场景描述：对前端发起的请求参数进行哈希运算（如MD5、SHA-256）生成签名，与参数一起传输

到后端，后端验证签名的有效性，防止请求参数被攻击者篡改。

• 实现方式：前端将请求参数按固定规则排序后，拼接密钥生成哈希值（签名），后端使用相同规则

和密钥验证签名。

• 典型案例：前端调用第三方接口时，对请求参数进行签名；支付页面的订单金额参数前端签名，防

止攻击者篡改金额。