JS 浏览器安全策略详解 - 同源策略与跨源资源共享的机制剖析-js教程-PHP中文网

同源策略（SOP）是浏览器安全的核心，通过限制协议、域名、端口不一致的跨源交互，防止恶意脚本读取敏感数据；它主要限制跨源DOM操作、XHR/Fetch请求的数据读取及Cookie等存储访问。为在安全前提下实现合法跨域，CORS机制应运而生，服务器通过设置Access-Control-Allow-Origin等响应头，明确授权允许的源、方法和头部，浏览器据此判断是否放行跨域请求，其中简单请求直接携带Origin头，复杂请求需先发送OPTIONS预检。此外，CSP、HSTS、X-Frame-Options、X-Content-Type-Options等机制共同构建了Web多层防御体系，分别防范XSS、中间人攻击、点击劫持和MIME嗅探等风险。

js 浏览器安全策略详解 - 同源策略与跨源资源共享的机制剖析

浏览器中的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 操作： 如果你的页面通过
```
<iframe>
```
登录后复制
嵌入了另一个不同源的页面，SOP会阻止父页面中的JavaScript访问或修改
```
<iframe>
```
登录后复制
内部的DOM结构，反之亦然。这防止了恶意网站通过嵌入合法网站的页面来实施点击劫持（Clickjacking）或窃取页面内容。比如，你不能让一个广告页面的脚本去修改你电商网站的结算按钮。
Cookie、LocalStorage、IndexedDB 等客户端存储： 这些存储机制也是严格按源隔离的。
```
https://a.com
```
登录后复制
的JavaScript无法读取或修改
```
https://b.com
```
登录后复制
存储的Cookie或其他本地数据。这保证了用户在不同网站上的会话信息和个人偏好不会被其他网站窃取或篡改，是保护用户隐私的关键一环。
JavaScript 文件的加载： 这一点可能容易被误解。实际上，SOP不限制跨源JavaScript文件的加载（通过
```
<script src="...">
```
登录后复制
），也不限制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

登录后复制

块中添加：

晓象AI资讯阅读神器

晓象-AI时代的资讯阅读神器

查看详情

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
```
登录后复制
或
```
<meta>
```
登录后复制
标签实现：
```
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';
```
登录后复制
这表示默认只允许加载同源资源，脚本可以来自同源或
```
https://cdn.example.com
```
登录后复制
，禁止
```
<object>
```
登录后复制
标签，
```
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）攻击。它允许网站管理员控制他们的页面是否可以被嵌入到
```
<frame>
```
登录后复制
、
```
<iframe>
```
登录后复制
或
```
<object>
```
登录后复制
中。
- ```
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
```
登录后复制
这对于确保浏览器正确处理你的资源类型，防止潜在的脚本执行漏洞非常重要。