跨域安全实现：JavaScript 通信最佳实践

在当今互联的 Web 中，JavaScript 应用程序经常需要与来自不同源（域、协议或端口）的资源进行交互。这种交互受到浏览器同源策略的制约，这是一种关键的安全机制，旨在防止恶意脚本跨域边界访问敏感数据。然而，合法的跨域通信通常是必要的。这就是跨域资源共享 (CORS) 发挥作用的地方。本文全面概述了 CORS、其实现以及在 JavaScript 中进行安全跨域通信的最佳实践。

理解同源策略

同源策略 (SOP) 是 Web 浏览器中的一个基本安全概念。它限制在一个源上运行的脚本访问来自不同源的资源。源由协议（例如 HTTP 或 HTTPS）、域名（例如 example.com）和端口号（例如 80 或 443）的组合定义。只有当所有这三个组件完全匹配时，两个 URL 才具有相同的源。

例如：

• http://www.example.com 和 http://www.example.com/path：同源
• http://www.example.com 和 https://www.example.com：不同源（协议不同）
• http://www.example.com 和 http://subdomain.example.com：不同源（域不同）
• http://www.example.com:80 和 http://www.example.com:8080：不同源（端口不同）

SOP 是抵御跨站脚本 (XSS) 攻击的关键防御措施，恶意脚本被注入网站后，可能窃取用户数据或代表用户执行未经授权的操作。

什么是跨域资源共享 (CORS)？

CORS 是一种机制，它使用 HTTP 标头来允许服务器指示哪些源（域、协议或端口）可以访问其资源。它实质上是为特定的跨域请求放宽了同源策略，从而在实现合法通信的同时，仍然能够防范恶意攻击。

CORS 通过添加新的 HTTP 标头来工作，这些标头指定了允许的源以及允许跨域请求的方法（例如 GET、POST、PUT、DELETE）。当浏览器发出跨域请求时，它会在请求中发送一个 Origin 标头。服务器则响应一个 Access-Control-Allow-Origin 标头，指明允许的源。如果请求的源与 Access-Control-Allow-Origin 标头中的值匹配（或者值为 *），浏览器就允许 JavaScript 代码访问响应。

CORS 工作原理：详细解释

CORS 过程通常涉及两种类型的请求：

1. 简单请求：这些是满足特定条件的请求。如果请求满足这些条件，浏览器会直接发送该请求。
2. 预检请求： 这些是更复杂的请求，需要浏览器首先向服务器发送一个“预检” OPTIONS 请求，以确定实际请求是否可以安全发送。

1. 简单请求

如果一个请求满足以下所有条件，则被认为是“简单”请求：

• 方法是 GET、HEAD 或 POST。
• 如果方法是 POST，则 Content-Type 标头是以下之一：
• application/x-www-form-urlencoded
• multipart/form-data
• text/plain
• 没有设置自定义标头。

简单请求示例：

GET /resource HTTP/1.1
Origin: http://www.example.com

允许该源的服务器响应示例：

HISTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Content-Type: application/json

{
  "data": "Some data"
}

如果 Access-Control-Allow-Origin 标头存在且其值与请求的源匹配或是 *，浏览器就允许脚本访问响应数据。否则，浏览器会阻止对响应的访问，并在控制台中显示错误消息。

2. 预检请求

如果一个请求不满足简单请求的条件，则被认为是“预检”请求。这通常发生在请求使用不同的 HTTP 方法（例如 PUT、DELETE）、设置自定义标头或使用允许值之外的 Content-Type 时。

在发送实际请求之前，浏览器首先向服务器发送一个 OPTIONS 请求。这个“预检”请求包含以下标头：

• Origin: 请求页面的源。
• Access-Control-Request-Method: 实际请求中将使用的 HTTP 方法（例如 PUT、DELETE）。
• Access-Control-Request-Headers: 一个逗号分隔的列表，包含实际请求中将发送的自定义标头。

预检请求示例：

OPTIONS /resource HTTP/1.1
Origin: http://www.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: X-Custom-Header, Content-Type

服务器必须用以下标头响应 OPTIONS 请求：

• Access-Control-Allow-Origin: 允许发出请求的源（或 * 以允许任何源）。
• Access-Control-Allow-Methods: 一个逗号分隔的列表，包含允许跨域请求的 HTTP 方法（例如 GET、POST、PUT、DELETE）。
• Access-Control-Allow-Headers: 一个逗号分隔的列表，包含允许在请求中发送的自定义标头。
• Access-Control-Max-Age: 浏览器可以缓存预检响应的秒数。

服务器对预检请求的响应示例：

HTTP/1.1 200 OK
Access-Control-Allow-Origin: http://www.example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: X-Custom-Header, Content-Type
Access-Control-Max-Age: 86400

如果服务器对预检请求的响应表明实际请求是允许的，浏览器随后将发送实际请求。否则，浏览器将阻止该请求并显示错误消息。

在服务器端实现 CORS

CORS 主要通过在响应中设置适当的 HTTP 标头在服务器端实现。具体的实现细节会根据所使用的服务器端技术而有所不同。

使用 Node.js 和 Express 的示例：

const express = require('express');
const cors = require('cors');
const app = express();

// 为所有源启用 CORS
app.use(cors());

// 或者，为特定源配置 CORS
// const corsOptions = {
//   origin: 'http://www.example.com'
// };
// app.use(cors(corsOptions));

app.get('/resource', (req, res) => {
  res.json({ message: '这是一个启用了 CORS 的资源' });
});

app.listen(3000, () => {
  console.log('服务器正在监听 3000 端口');
});

cors 中间件简化了在 Express 中设置 CORS 标头的过程。您可以使用 cors() 为所有源启用 CORS，或使用 cors(corsOptions) 为特定源进行配置。

使用 Python 和 Flask 的示例：

from flask import Flask
from flask_cors import CORS

app = Flask(__name__)
CORS(app)

@app.route("/resource")
def hello():
    return {"message": "这是一个启用了 CORS 的资源"}

if __name__ == '__main__':
    app.run(debug=True)

flask_cors 扩展为在 Flask 应用程序中启用 CORS 提供了一种简单的方法。您可以通过将 app 传递给 CORS() 来为所有源启用 CORS。也可以为特定源进行配置。

使用 Java 和 Spring Boot 的示例：

import org.springframework.context.annotation.Configuration;
import org.springframework.web.servlet.config.annotation.CorsRegistry;
import org.springframework.web.servlet.config.annotation.WebMvcConfigurer;

@Configuration
public class CorsConfig implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(CorsRegistry registry) {
        registry.addMapping("/resource")
                .allowedOrigins("http://www.example.com")
                .allowedMethods("GET", "POST", "PUT", "DELETE")
                .allowedHeaders("Content-Type", "X-Custom-Header")
                .allowCredentials(true)
                .maxAge(3600);
    }
}

在 Spring Boot 中，您可以使用 WebMvcConfigurer 配置 CORS。这允许对允许的源、方法、标头和其他 CORS 设置进行细粒度控制。

直接设置 CORS 标头（通用示例）

如果您不使用任何框架，可以直接在服务器端代码中设置标头（例如 PHP、Ruby on Rails 等）：

CORS 最佳实践

为确保安全高效的跨域通信，请遵循以下最佳实践：

1. 在生产环境中避免使用 Access-Control-Allow-Origin: *：允许所有源访问您的资源可能存在安全风险。相反，应明确指定允许的源。
2. 使用 HTTPS：请求和提供服务的源都应始终使用 HTTPS，以保护传输中的数据。
3. 验证输入：始终验证和清理从跨域请求接收的数据，以防止注入攻击。
4. 实施适当的身份验证和授权：确保只有授权用户才能访问敏感资源。
5. 缓存预检响应：使用 Access-Control-Max-Age 缓存预检响应，以减少 OPTIONS 请求的数量。
6. 考虑使用凭据：如果您的 API 需要使用 cookie 或 HTTP 身份验证，您需要在服务器上将 Access-Control-Allow-Credentials 标头设置为 true，并在您的 JavaScript 代码中将 credentials 选项设置为 'include'（例如，在使用 fetch 或 XMLHttpRequest 时）。使用此选项时要格外小心，因为如果处理不当，可能会引入安全漏洞。此外，当 Access-Control-Allow-Credentials 设置为 true 时，Access-Control-Allow-Origin 不能设置为“*”。您必须明确指定允许的源。
7. 定期审查和更新 CORS 配置：随着应用程序的发展，定期审查和更新您的 CORS 配置，以确保其保持安全并满足您的需求。
8. 理解不同 CORS 配置的含义：了解不同 CORS 配置的安全影响，并选择适合您应用程序的配置。
9. 测试您的 CORS 实现：彻底测试您的 CORS 实现，以确保其按预期工作，并且没有引入任何安全漏洞。使用浏览器开发人员工具检查网络请求和响应，并使用自动化测试工具验证 CORS 行为。

示例：使用 Fetch API 处理 CORS

以下是如何使用 fetch API 发出跨域请求的示例：

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors', // 告诉浏览器这是一个 CORS 请求
  headers: {
    'Content-Type': 'application/json',
    'X-Custom-Header': 'value'
  }
})
.then(response => {
  if (!response.ok) {
    throw new Error('网络响应不正常');
  }
  return response.json();
})
.then(data => {
  console.log(data);
})
.catch(error => {
  console.error('fetch 操作出现问题：', error);
});

mode: 'cors' 选项告诉浏览器这是一个 CORS 请求。如果服务器不允许该源，浏览器将阻止访问响应，并会抛出一个错误。

如果您正在使用凭据（例如 cookie），则需要将 credentials 选项设置为 'include'：

fetch('https://api.example.com/data', {
  method: 'GET',
  mode: 'cors',
  credentials: 'include', // 在请求中包含 cookie
  headers: {
    'Content-Type': 'application/json'
  }
})
.then(response => {
  // ...
});

CORS 和 JSONP

JSON with Padding (JSONP) 是一种绕过同源策略的旧技术。它通过动态创建一个从不同域加载数据的 <script> 标签来工作。虽然 JSONP 在某些情况下可能有用，但它有严重的安全限制，应尽可能避免使用。CORS 是跨域通信的首选解决方案，因为它提供了更安全、更灵活的机制。

CORS 和 JSONP 的主要区别：

• 安全性：CORS 比 JSONP 更安全，因为它允许服务器控制哪些源可以访问其资源。JSONP 不提供任何源控制。
• HTTP 方法：CORS 支持所有 HTTP 方法（例如 GET、POST、PUT、DELETE），而 JSONP 仅支持 GET 请求。
• 错误处理：CORS 提供比 JSONP 更好的错误处理。当 CORS 请求失败时，浏览器会提供详细的错误消息。JSONP 的错误处理仅限于检测脚本是否成功加载。

CORS 问题排查

调试 CORS 问题可能会令人沮丧。以下是一些常见的故障排除技巧：

• 检查浏览器控制台：浏览器控制台通常会提供有关 CORS 问题的详细错误消息。
• 检查网络请求：使用浏览器的开发人员工具检查请求和响应的 HTTP 标头。验证 Origin 和 Access-Control-Allow-Origin 标头是否设置正确。
• 验证服务器端配置：仔细检查您的服务器端 CORS 配置，确保它允许正确的源、方法和标头。
• 清除浏览器缓存：有时，缓存的预检响应可能会导致 CORS 问题。尝试清除浏览器缓存或使用隐私浏览窗口。
• 使用 CORS 代理：在某些情况下，您可能需要使用 CORS 代理来绕过 CORS 限制。但是，请注意使用 CORS 代理可能会引入安全风险。
• 检查配置错误：查找常见的配置错误，例如缺少 Access-Control-Allow-Origin 标头、不正确的 Access-Control-Allow-Methods 或 Access-Control-Allow-Headers 值，或请求中不正确的 Origin 标头。

结论

跨域资源共享 (CORS) 是在 JavaScript 应用程序中实现安全跨域通信的基本机制。通过理解同源策略、CORS 工作流程以及所涉及的各种 HTTP 标头，开发人员可以有效地实施 CORS，以保护其应用程序免受安全漏洞的侵害，同时允许合法的跨域请求。遵循 CORS 配置的最佳实践并定期审查您的实现，对于维护一个安全稳健的 Web 应用程序至关重要。

这份综合指南为理解和实施 CORS 提供了坚实的基础。请记得查阅您特定服务器端技术的官方文档和资源，以确保您正确且安全地实施 CORS。

更多资源

• MDN Web 文档：跨域资源共享 (CORS)
• W3C：跨域资源共享 (CORS)
• PortSwigger Web 安全学院：CORS