【WEB】CORS 配置的进阶技巧与注意事项

引言

跨域资源共享（CORS，Cross-Origin Resource Sharing）是现代 Web 开发中非常重要的技术，它解决了浏览器出于安全考虑对不同源之间请求的限制问题。为了能够在前端与后端之间安全、灵活地进行数据交换，CORS 配置变得尤为重要。随着 Web 应用和 API 复杂度的增加，开发者需要更深入地理解和配置 CORS 本机制。本文将深入探讨 CORS 配置的进阶技巧、注意事项，并提供详细的代码示例、注释及图示。

一、动态设置 CORS 响应头

1.1 什么是动态 CORS 配置？

动态 CORS 配置的核心思想是根据请求的来源（Origin）动态决定是否允许跨域访问。这是一个非常常见的需求，因为很多 Web 应用并非只服务一个固定的域，而是需要灵活支持多个域的跨域请求。

示例：动态设置 CORS 配置（Node.js）

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

// CORS 中间件，动态设置 Access-Control-Allow-Origin
app.use((req, res, next) => {
  const allowedOrigins = ['https://www.example1.com', 'https://www.example2.com'];
  const origin = req.headers.origin;

  if (allowedOrigins.includes(origin)) {
    res.setHeader('Access-Control-Allow-Origin', origin); // 允许的来源
  } else {
    res.setHeader('Access-Control-Allow-Origin', ''); // 不允许其他来源
  }

  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Access-Control-Allow-Credentials', 'true'); // 允许带上 cookies

  next();
});

// 简单接口返回数据
app.get('/data', (req, res) => {
  res.json({ message: 'This is data' });
});

app.listen(3000, () => console.log('Server is running on port 3000'));

解释与扩展：

1. 动态检查请求来源：根据请求头中的 Origin 动态设置 Access-Control-Allow-Origin，如果请求来源在允许的域名列表中，就允许跨域请求。
2. 跨域控制：通过响应头部设置，除了允许的来源之外，其他域名的请求都无法跨域访问。

这种方法适用于多个域名需要访问同一个 API，但并非所有的域都可以进行跨域访问的场景。

1.2 为什么需要动态设置 CORS？

动态设置 CORS 响应头的原因可以总结为：

• 安全性：你可以确保只有经过验证和信任的域才能访问你的资源。
• 灵活性：不同的子域或独立的 Web 应用可以被允许访问 API，而其他不需要的域则会被拒绝。

例如，假设你有一个在线商城 API，它需要允许来自多个子域（如 www.example.com 和 shop.example.com）的请求，但不希望允许其他未经验证的域名。

1.3 动态 CORS 配置的注意事项

• 性能问题：每次请求时都要检查域名是否在白名单中，可能会影响性能。为了优化性能，可以使用缓存机制，避免每次都进行动态计算。
• 安全性问题：对于不信任的域名，需要确保严格验证来源，避免攻击者通过伪造的请求获取数据。

二、设置 Access-Control-Allow-Credentials 为 true

2.1 什么是 Access-Control-Allow-Credentials？

Access-Control-Allow-Credentials 是一个 CORS 响应头，用来指示浏览器在发起跨域请求时是否允许携带用户凭证（如 cookies、HTTP 认证信息等）。默认情况下，跨域请求不会携带这些凭证，除非显式设置。

示例：带凭证的跨域请求（前端）

fetch('https://api.example.com/data', {
  method: 'GET',
  credentials: 'include', // 允许携带 cookies
  headers: {
    'Authorization': 'Bearer token'
  }
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

在上面的代码中，credentials: 'include' 表示跨域请求时允许携带 cookies 等认证信息。

后端设置 Access-Control-Allow-Credentials

app.use(cors({
  origin: 'https://www.example.com',  // 只允许特定的域访问
  credentials: true,  // 允许携带 cookies
  methods: ['GET', 'POST', 'PUT'],
}));

2.2 为什么需要 Access-Control-Allow-Credentials？

允许凭证跨域访问的场景通常包括：

• 认证：当用户已登录时，前端需要携带凭证（如 cookies 或 HTTP 认证信息）以进行身份验证。
• 权限管理：只有经过认证的用户才可以访问特定的资源，开启凭证支持可以确保请求附带用户信息。

2.3 Access-Control-Allow-Credentials 的常见错误

• 错误配置：当你设置 credentials: true 时，Access-Control-Allow-Origin 不能是 *。必须明确指定允许的来源。

错误示例：

// 错误配置，不能同时使用 * 和 credentials: true
app.use(cors({
  origin: '*',
  credentials: true
}));

解决方法：

// 正确配置，明确指定 origin
app.use(cors({
  origin: 'https://www.example.com', // 明确的域名
  credentials: true
}));

三、处理 CORS 的预检请求

3.1 什么是预检请求？

预检请求（preflight request）是浏览器在发起复杂的跨域请求之前，自动向服务器发送的 OPTIONS 请求。它的作用是询问服务器是否允许特定的跨域操作。预检请求通常在请求方法为 PUT、DELETE，或者请求头中包含自定义字段时发起。

3.2 如何处理预检请求？

服务器必须能够正确响应预检请求，否则浏览器将无法继续进行实际的跨域请求。

示例：处理预检请求（Node.js）

app.options('*', (req, res) => {
  res.setHeader('Access-Control-Allow-Origin', '*');
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, PUT, DELETE, OPTIONS');
  res.setHeader('Access-Control-Allow-Headers', 'Content-Type, Authorization');
  res.setHeader('Access-Control-Max-Age', '86400');  // 预检请求缓存24小时
  res.send();
});

在这个例子中，我们通过 app.options('*') 来处理所有的预检请求，并返回必要的 CORS 头信息。设置 Access-Control-Max-Age 为 86400 秒（24 小时），使得浏览器在 24 小时内无需再次发起预检请求。

3.3 预检请求的常见问题

• 问题：预检请求未得到正确响应。
  解决方法：确保服务器能够响应 OPTIONS 请求，并且响应中包含 Access-Control-Allow-Methods、Access-Control-Allow-Headers 等头部信息。

四、跨域请求时的 Authorization 头部问题

4.1 Authorization 头部的 CORS 配置

在跨域请求中，Authorization 头部常用于携带令牌（如 Bearer Token）。为了允许浏览器发送带有 Authorization 头部的跨域请求，服务器需要显式地允许该头部。

示例：允许 Authorization 头部（Node.js）

app.use(cors({
  allowedHeaders: ['Content-Type', 'Authorization'], // 允许自定义头部
}));

4.2 Authorization 头部常见问题

• 问题：服务器没有正确配置允许 Authorization 头部，导致浏览器拒绝请求。
  解决方法：在 CORS 响应头中明确列出 Authorization，使浏览器能够接受该头部。

五、特定路径的 CORS 配置

5.1 配置特定路径的 CORS 策略

有时我们不希望为整个应用启用 CORS，而是只为某些 API 路径启用跨域请求。可以通过为特定的路由配置 CORS 来实现。

示例：仅为特定路径启用 CORS（Express）

const cors = require('cors');

// 仅为 /public-api 路径启用 CORS
app.get('/public-api', cors(), (req, res) => {
  res.json({ message: 'This is a public API' });
});

// /private-api 路径不启用 CORS
app.get('/private-api', (req, res) =>```javascript
  res.json({ message: 'This is a private API' });
});

解释：

在这个例子中，我们为 /public-api 路径单独配置了 CORS（通过 cors() 中间件），而 /private-api 路径没有启用 CORS 策略。这使得你能够精确控制哪些 API 可以跨域访问，哪些不能。这样能够根据 API 的敏感性，选择性地允许或拒绝跨域请求。

这种方式常见于有部分开放 API 和部分私密 API 的情况。例如，某些公共资源可能需要对外开放，而某些涉及敏感数据的资源则需要严格的跨域访问控制。

5.2 为特定路径设置动态 CORS

如果你需要根据请求的具体路径或者请求头来动态配置 CORS（比如允许某些请求路径携带不同的凭证），你可以针对每个路径分别定义不同的 CORS 策略。

app.use('/api/public', cors({
  origin: 'https://www.example.com',
  methods: ['GET', 'POST'],
  credentials: true,
}));

app.use('/api/private', cors({
  origin: 'https://www.private-allowed.com',
  methods: ['GET'],
  credentials: false,
}));

5.3 路由级别的 CORS 配置注意事项

• 优先级：路由级别的 CORS 配置通常优先于全局配置，具体顺序可以参考应用的中间件顺序。
• 灵活性与控制：当你的应用中有多个不同的资源时，通过为不同路径配置 CORS，你可以灵活地控制哪些 API 路径可以接受跨域请求，哪些不能。

六、CORS 与 JWT（JSON Web Token）

6.1 结合 JWT 进行身份验证

在现代 Web 开发中，JWT 通常用于用户身份验证。为了确保 CORS 请求能够携带有效的 JWT 令牌，你需要正确配置 CORS 响应头，允许带上 Authorization 头部，并在服务器端进行验证。

前端：发送带有 JWT 的请求

fetch('https://api.example.com/protected-data', {
  method: 'GET',
  headers: {
    'Authorization': 'Bearer your-jwt-token-here'
  },
  credentials: 'include' // 携带 cookies（如果有）
})
  .then(response => response.json())
  .then(data => console.log(data))
  .catch(error => console.error('Error:', error));

后端：配置 CORS 以允许携带 JWT

app.use(cors({
  origin: 'https://www.frontend.com',
  credentials: true,  // 允许跨域请求携带凭证
  allowedHeaders: ['Content-Type', 'Authorization'],  // 允许带 Authorization 头部
}));

6.2 CORS 与 JWT 的挑战

• 安全性：确保 Access-Control-Allow-Origin 不使用 *，因为这会暴露 JWT 等敏感数据给不受信任的域。
• 跨域 Cookies：若你希望跨域请求时带上 cookies，必须设置 credentials: 'include'，并且后端响应中 Access-Control-Allow-Credentials 必须设置为 true。

JWT 配合 CORS 使用的安全建议：

• 使用 HTTPS 保护数据传输。
• JWT 的存储要注意安全，不要直接存储在浏览器的 localStorage 中，而是存储在 httpOnly cookies 中，这样能有效防止 XSS 攻击。

七、CORS 的调试技巧

7.1 使用浏览器开发者工具

大部分浏览器（如 Chrome、Firefox）提供了开发者工具，能够方便地查看跨域请求的详细信息，包括请求头、响应头以及 CORS 错误信息。具体操作如下：

1. 打开浏览器开发者工具（F12 或右键点击页面选择“检查”）。
2. 转到“Network”标签页，查看你的跨域请求。
3. 如果发生 CORS 错误，你通常会在控制台看到类似以下的信息：
   • Access to XMLHttpRequest at 'https://api.example.com' from origin 'https://www.frontend.com' has been blocked by CORS policy
   • CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status

7.2 CORS 错误的常见排查步骤

• 检查响应头：确保响应中包含正确的 CORS 头部，特别是 Access-Control-Allow-Origin、Access-Control-Allow-Methods 和 Access-Control-Allow-Headers。
• 查看预检请求：预检请求（OPTIONS 请求）需要正确响应，返回必要的 CORS 信息（如 Access-Control-Allow-Methods）。
• 确认 CORS 配置是否与客户端请求匹配：例如，客户端是否在请求中发送了某些自定义头部，后端是否允许这些头部。

总结与最佳实践

CORS 配置是确保 Web 应用跨域安全访问的关键。正确理解 CORS 策略、合理配置 CORS 响应头以及处理复杂的跨域场景至关重要。以下是一些最佳实践：

• 严格控制 Access-Control-Allow-Origin：避免使用 *，特别是在涉及用户认证和敏感数据的 API 上。
• 开启预检请求的缓存：通过 Access-Control-Max-Age 设置预检请求的缓存时间，减少不必要的请求。
• 支持凭证（cookies、HTTP 认证）时，确保设置 credentials 为 true。
• 为不同路径配置不同的 CORS 策略：针对公开和私密 API 路径采用不同的跨域策略。
• 调试 CORS 错误时，关注浏览器控制台和开发者工具：这将帮助你快速定位配置问题。

通过这些技巧和最佳实践，你可以更好地理解并掌控 CORS，确保 Web 应用的跨域通信既安全又高效。

---