同源策略（SOP）是浏览器安全的核心，通过限制协议、域名、端口不一致的跨源交互，防止恶意脚本读取敏感数据；它主要限制跨源DOM操作、XHR/Fetch请求的数据读取及Cookie等存储访问。为在安全前提下实现合法跨域，CORS机制应运而生，服务器通过设置Access-Control-Allow-Origin等响应头，明确授权允许的源、方法和头部，浏览器据此判断是否放行跨域请求，其中简单请求直接携带Origin头，复杂请求需先发送OPTIONS预检。此外，CSP、HSTS、X-Frame-Options、X-Content-Type-Options等机制共同构建了Web多层防御体系，分别防范XSS、中间人攻击、点击劫持和MIME嗅探等风险。
浏览器中的JavaScript安全，说到底，很大程度上就是围绕着两个核心概念展开的：同源策略（Same-Origin Policy, SOP）和跨源资源共享（Cross-Origin Resource Sharing, CORS）。简单来说，同源策略是浏览器对JavaScript施加的一道默认“防火墙”，它严格限制了不同源的文档或脚本之间的交互，以防范恶意行为。而CORS呢，则可以看作是这道防火墙上一个经过精心设计的“通行证”系统，它允许服务器明确授权，让特定源的客户端脚本能够安全地访问其资源，打破了SOP的僵硬限制，但又保持了必要的安全控制。理解它们，是每一个前端开发者构建健壮、安全应用的基石。
同源策略（SOP）是浏览器安全的核心机制，它的存在，在我看来，就是为了防止一个恶意网站的脚本去读取或操作另一个网站的数据。想象一下，如果没有SOP，你访问了一个钓鱼网站，它上面的JavaScript就能轻而易举地读取你银行网站的Cookie，甚至是直接向银行发送请求，获取你的账户信息。这想想都觉得可怕。SOP的判断标准很简单，但又很严格：协议、域名、端口号，三者都必须完全一致，才被认为是“同源”。只要有一个不同，就视为“跨源”。
SOP主要限制了以下几类操作：
DOM操作： 跨源的iframe内容无法被父页面或子页面中的JavaScript直接访问和修改。这防止了恶意网站通过嵌入合法网站的iframe来窃取信息或篡改页面。XMLHttpRequest/Fetch API请求： 这是我们平时接触最多的限制。浏览器默认不允许JavaScript发起跨源的XHR或Fetch请求去读取响应内容。你可以发送请求（比如GET请求），但如果响应来自不同源，JavaScript是无法获取响应数据的。当然，某些简单请求（如GET/POST，且Content-Type限制）是允许发送的，但读取响应依然受限。Cookie、LocalStorage、IndexedDB等存储： 这些客户端存储机制也严格遵循同源策略。一个源的脚本无法访问另一个源的存储数据。
这些限制，就像是给每个网站的数据和功能都划上了一道清晰的边界，确保了它们之间的独立性和安全性。没有SOP，互联网将是一个混乱且危险的地方。
同源策略究竟限制了什么？它如何保护我的网站安全？
同源策略，说白了，就是浏览器为了保护用户数据和网站安全而设立的一道基本防线。它限制了不同源的文档或脚本之间进行某些关键的交互。在我看来，理解这些限制比单纯记住“三要素”要重要得多，因为这直接关系到我们如何设计和开发安全的Web应用。
它限制的核心，主要体现在以下几个方面：
XMLHttpRequest (XHR) 和 Fetch API 请求： 这是最常见也是最让人头疼的限制。当你的前端代码（例如运行在
https://a.com
）尝试通过
fetch
或
XHR
向
https://b.com/api
发送请求并读取其响应时，浏览器会默认阻止。这意味着，即便用户访问了你的网站，恶意脚本也无法直接向其他网站（比如用户的银行网站）发送请求并获取敏感数据，从而有效防止了信息泄露和未经授权的操作。当然，你可以发送一些“简单请求”（Simple Request），但你无法读取响应内容，这本身就是一种保护。DOM 操作： 如果你的页面通过
嵌入了另一个不同源的页面，SOP会阻止父页面中的JavaScript访问或修改
内部的DOM结构，反之亦然。这防止了恶意网站通过嵌入合法网站的页面来实施点击劫持（Clickjacking）或窃取页面内容。比如，你不能让一个广告页面的脚本去修改你电商网站的结算按钮。Cookie、LocalStorage、IndexedDB 等客户端存储： 这些存储机制也是严格按源隔离的。
https://a.com
的JavaScript无法读取或修改
https://b.com
存储的Cookie或其他本地数据。这保证了用户在不同网站上的会话信息和个人偏好不会被其他网站窃取或篡改，是保护用户隐私的关键一环。JavaScript 文件的加载： 这一点可能容易被误解。实际上，SOP不限制跨源JavaScript文件的加载（通过
），也不限制CSS、图片等静态资源的加载。这正是CDN能够工作的基础。但即使加载了，这个跨源脚本的执行环境仍然受限于它所在的页面，它也无法突破SOP去访问其他源的资源。
SOP通过这些限制，构建了一个相对隔离的沙箱环境，确保了各个网站在浏览器中的运行互不干扰，极大地提升了Web应用的安全性。没有它，Web世界会变得异常脆弱，各种跨站攻击将无孔不入。
跨域资源共享（CORS）的工作原理是什么？我该如何正确配置它？
CORS，在我看来，就是为了在保证SOP安全性的前提下，提供一种“协商”机制，让不同源的网站之间能够安全地共享资源。它不是绕过SOP，而是在SOP的框架下，通过HTTP头部信息，明确告知浏览器哪些跨域请求是合法的。
CORS的工作原理，核心在于浏览器和服务器之间的一系列HTTP头部通信。它根据请求的“复杂程度”分为两种：
简单请求（Simple Request）：
请求方法是
GET
、
POST
或
HEAD
。HTTP头信息中没有自定义的请求头，且
Content-Type
只能是
application/x-www-form-urlencoded
、
multipart/form-data
或
text/plain
。对于简单请求，浏览器会直接发送请求，并在请求头中自动带上
Origin
字段，表明请求的来源。服务器收到请求后，如果允许该源访问，就会在响应头中添加
Access-Control-Allow-Origin
字段，其值要么是请求的
Origin
，要么是
*
（表示允许所有源）。浏览器接收到响应后，会检查
Access-Control-Allow-Origin
，如果匹配，就将响应内容暴露给前端JavaScript；否则，就会阻止JavaScript获取响应。
预检请求（Preflight Request）：
如果请求不符合简单请求的条件（例如使用了
PUT
、
DELETE
方法，或者自定义了请求头，或者
Content-Type
是
application/json
等），浏览器在发送实际请求之前，会先发送一个
OPTIONS
方法的预检请求。这个预检请求会包含
Access-Control-Request-Method
（告知服务器实际请求将使用的方法）和
Access-Control-Request-Headers
（告知服务器实际请求将包含的自定义头部）。服务器收到预检请求后，会根据这些信息判断是否允许跨域。如果允许，它会在响应头中包含
Access-Control-Allow-Origin
、
Access-Control-Allow-Methods
、
Access-Control-Allow-Headers
等字段。此外，
Access-Control-Max-Age
字段可以指定预检请求的缓存时间，避免每次都发送预检。浏览器接收到预检响应后，如果确认允许，才会发送真正的跨域请求。如果预检失败，实际请求就不会发出。
如何正确配置CORS？
CORS的配置主要在服务器端进行。前端代码无需做特殊处理，只需要正常发起跨域请求即可。服务器端需要根据业务需求，在响应头中添加相应的
Access-Control-*
字段。
以下是一些常见的配置示例：
1. 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-Origin', 'https://your-frontend-domain.com'); // 允许的请求方法 res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS'); // 允许的请求头 res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization, X-Requested-With'); // 允许发送Cookie等凭证信息（重要！如果需要携带Cookie，Origin不能是*） res.setHeader('Access-Control-Allow-Credentials', 'true'); // 预检请求的缓存时间 res.setHeader('Access-Control-Max-Age', '3600'); // 处理OPTIONS预检请求 if (req.method === 'OPTIONS') { res.sendStatus(200); } else { next(); }});// 你的API路由app.get('/api/data', (req, res) => { res.json({ message: 'Hello from CORS API!' });});app.listen(3000, () => { console.log('Server running on port 3000');});
2. Nginx 配置:
在Nginx的
http
、
server
或
location
块中添加：
server { listen 80; server_name api.example.com; location / { # 允许所有源访问 add_header 'Access-Control-Allow-Origin' '*'; # 或者指定具体源 # add_header 'Access-Control-Allow-Origin' 'https://your-frontend-domain.com'; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Max-Age' 1728000; # 处理OPTIONS预检请求 if ($request_method = 'OPTIONS') { add_header 'Access-Control-Allow-Origin' '*'; add_header 'Access-Control-Allow-Methods' 'GET, POST, PUT, DELETE, OPTIONS'; add_header 'Access-Control-Allow-Headers' 'DNT,X-CustomHeader,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Authorization'; add_header 'Access-Control-Allow-Credentials' 'true'; add_header 'Access-Control-Max-Age' 1728000; add_header 'Content-Length' 0; return 204; } # 其他代理或文件服务配置 proxy_pass http://backend_server; }}
配置时的注意事项：
Access-Control-Allow-Origin
： 生产环境中，尽量不要设置为
*
，而应该明确指定允许的源（如
https://your-frontend-domain.com
）。如果需要支持多个源，服务器端需要根据请求的
Origin
动态设置该值。
Access-Control-Allow-Credentials
： 当这个头设置为
true
时，表示服务器允许浏览器发送附带凭证（如Cookie、HTTP认证）的跨域请求。*此时，
Access-Control-Allow-Origin
绝对不能是 ``，必须指定具体的源。** 否则，浏览器会拒绝请求。
Access-Control-Allow-Methods
和
Access-Control-Allow-Headers
： 明确列出你的API支持的HTTP方法和允许的自定义请求头。预检请求处理： 确保你的服务器能够正确响应
OPTIONS
请求，并且返回正确的CORS头部。
CORS的正确配置，是在开放性和安全性之间取得平衡的关键。它让开发者能够安全地构建现代Web应用中常见的微服务架构和前后端分离模式。
除了同源策略和CORS，还有哪些浏览器安全机制值得关注？
当然，浏览器安全远不止同源策略和CORS这么简单，它们只是冰山一角。作为一个开发者，我觉得我们有必要去了解更多，因为这些机制共同构筑了我们所依赖的Web安全环境。在我看来，以下几个机制同样重要，它们各自解决不同的安全问题，但又互为补充：
内容安全策略（Content Security Policy, CSP）：CSP是一种强大的安全机制，它允许网站管理员通过定义一系列策略，来限制页面可以加载哪些资源（脚本、样式、图片、字体、媒体等）以及如何执行脚本。这就像给你的网页设定了一份“白名单”，只有符合白名单规则的资源才会被加载和执行。它的主要目的是防止跨站脚本攻击（XSS）和数据注入攻击。
举个例子，你可以配置CSP只允许加载来自你的域名和某个CDN的脚本，禁止内联脚本和
eval()
的使用。这样，即使攻击者成功注入了恶意脚本，浏览器也会因为不符合CSP策略而拒绝执行，大大降低了XSS的风险。
配置通常通过HTTP响应头
Content-Security-Policy
或
标签实现：
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';
这表示默认只允许加载同源资源，脚本可以来自同源或
https://cdn.example.com
，禁止
标签，
base
标签的URI必须同源。
HTTP Strict Transport Security (HSTS)：HSTS是一种HTTP响应头，它强制浏览器在未来的一段时间内，始终通过HTTPS与你的网站进行通信，即使用户在地址栏中输入的是HTTP。这可以有效防止中间人攻击（Man-in-the-Middle, MITM），避免用户在不安全的HTTP连接上暴露敏感信息。
当浏览器第一次访问一个设置了HSTS的网站时，它会记住这个策略。下次用户再访问这个网站时，即便输入的是
http://example.com
，浏览器也会自动将其重定向到
https://example.com
。
配置示例：
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
max-age
指定了HSTS策略的有效期（秒），
includeSubDomains
表示也适用于所有子域名，
preload
是一个预加载列表，让浏览器提前知道哪些网站应该始终使用HTTPS。
X-Frame-Options：这个HTTP响应头主要用于防止点击劫持（Clickjacking）攻击。它允许网站管理员控制他们的页面是否可以被嵌入到
、
或
中。
DENY
：不允许任何网站嵌入该页面。
SAMEORIGIN
：只允许同源的网站嵌入该页面。
ALLOW-FROM uri
：允许指定URI的网站嵌入该页面（现代浏览器支持有限，不推荐）。
配置示例：
X-Frame-Options: SAMEORIGIN
通过这个简单的头部，你可以确保你的页面不会被恶意网站嵌入，从而防止用户在不知情的情况下点击了恶意链接或执行了恶意操作。
X-Content-Type-Options：这个HTTP响应头用于防止MIME类型嗅探（MIME Sniffing）攻击。浏览器通常会尝试猜测资源的MIME类型，即使服务器在
Content-Type
头中指定了类型。这可能导致一些安全问题，例如将一个看似无害的文本文件误识别为可执行脚本。
设置
X-Content-Type-Options: nosniff
可以指示浏览器禁用MIME类型嗅探，强制它使用服务器指定的
Content-Type
。
配置示例：
X-Content-Type-Options: nosniff
这对于确保浏览器正确处理你的资源类型，防止潜在的脚本执行漏洞非常重要。
这些机制各有侧重，共同构建了一个多层次的Web安全防御体系。作为开发者，了解并合理运用它们，是保障Web应用安全不可或缺的一部分。我们不能只盯着SOP和CORS，而忽略了其他同样关键的环节。
以上就是JS 浏览器安全策略详解 – 同源策略与跨源资源共享的机制剖析的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1521752.html
微信扫一扫 
支付宝扫一扫 
