Web跨域问题

漆黑的莫莫

于 2024-08-07 11:05:30 发布

阅读量601

点赞数 20

文章标签：前端

本文链接：https://blog.csdn.net/qq_45831414/article/details/140985640

版权

1. 概念

跨域：当两个资源（如网页与API服务）位于不同的域名、协议或端口时，浏览器出于安全原因会阻止这些资源之间的交互。这种限制称为同源策略（Same-origin policy）。
CORS (Cross-Origin Resource Sharing)：一种机制，允许服务器明确指定哪些来源可以访问其资源。服务器通过响应头中的特定字段来控制跨域行为。

2. 开发环境中的处理

前端开发服务器代理：
- 开发服务器（如Webpack Dev Server、Create React App等）提供代理功能，可以将API请求代理到后端服务器。
- 代理配置仅在开发环境中生效，不会影响生产环境。

3. 生产环境中的处理

后端服务配置：
- 后端服务通过响应头设置允许跨域访问。
- 例如，使用Node.js的cors中间件或者在Java Spring框架中通过配置实现。
反向代理服务器配置：
- 使用Nginx等反向代理服务器为后端API添加跨域支持。
- Nginx配置可以添加Access-Control-Allow-Origin等响应头。

4. 示例配置

Nginx配置示例：
- 配置Nginx来处理所有到达后端API的请求，并添加必要的跨域响应头。
- 示例配置：

server {
    # 监听80端口，这是标准的HTTP端口
    listen 80;
    
    # 设置服务器名称，客户端通过这个域名访问此服务器
    server_name example.com;

    # 针对/api/路径下的所有请求进行代理
    location /api/ {
        # 将请求代理到后端服务器，这里假设后端服务器地址为http://backend-server
        proxy_pass http://backend-server;

        # 设置代理请求头中的Host字段为客户端请求的原始主机名
        proxy_set_header Host $host;

        # 设置代理请求头中的X-Real-IP字段为客户端的真实IP地址
        proxy_set_header X-Real-IP $remote_addr;

        # CORS相关的响应头设置
        # 允许任何源访问此API
        add_header 'Access-Control-Allow-Origin' '*';

        # 允许GET, POST和OPTIONS方法
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';

        # 允许客户端发送自定义请求头，比如X-Requested-With, Content-Type, Authorization
        add_header 'Access-Control-Allow-Headers' 'X-Requested-With, Content-Type, Authorization';

        # 指定客户端可以从响应中访问的额外头部字段，例如自定义头部Custom-Header
        add_header 'Access-Control-Expose-Headers' 'Custom-Header';

        # 预检请求的有效期为20天
        add_header 'Access-Control-Max-Age' 1728000;

        # 允许客户端发送和接收cookies、HTTP认证信息等
        add_header 'Access-Control-Allow-Credentials' 'true';
    }
}

5. CORS 响应头详解

Access-Control-Allow-Origin: 指定允许跨域请求的源。可以是一个具体的URL，也可以是通配符*表示允许所有源。
- 例子:
  - 允许所有源访问:
```
Access-Control-Allow-Origin: *
```
  - 仅允许https://example.com访问:
```
Access-Control-Allow-Origin: https://example.com
```
Access-Control-Allow-Methods: 允许的HTTP方法列表，如GET, POST, PUT, DELETE等。
- 例子:
  - 允许GET和POST方法:
```
Access-Control-Allow-Methods: GET, POST
```
  - 允许所有HTTP方法:
```
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
```
Access-Control-Allow-Headers: 允许客户端发送的自定义HTTP头部字段。
- 例子:
  - 允许Content-Type和Authorization头部:
```
Access-Control-Allow-Headers: Content-Type, Authorization
```
  - 允许所有头部:
```
Access-Control-Allow-Headers: *
```
Access-Control-Expose-Headers: 指定客户端可以从响应中访问的额外头部字段。
- 例子:
  - 允许客户端访问X-Custom-Header头部:
```
Access-Control-Expose-Headers: X-Custom-Header
```
  - 允许访问多个头部:
```
Access-Control-Expose-Headers: X-Custom-Header, X-Another-Header
```
Access-Control-Max-Age: 规定了预检请求（OPTIONS请求）的有效期，单位是秒。
- 例子:
  - 预检请求有效期为1天:
```
Access-Control-Max-Age: 86400
```
  - 预检请求有效期为20天:
```
Access-Control-Max-Age: 1728000
```
Access-Control-Allow-Credentials: 如果设置为true，则允许客户端发送和接收cookies、HTTP认证信息等。
- 例子:
  - 允许凭证:
```
Access-Control-Allow-Credentials: true
```
  - 不允许凭证:
```
Access-Control-Allow-Credentials: false
```

6. 预检请求（Preflight Request）

当请求满足以下条件之一时，浏览器会先发送一个预检请求（也称为OPTIONS请求）：
- 请求方法不是GET, HEAD, 或POST。
- 请求方法是POST，但包含非简单头部（如Content-Type不是application/x-www-form-urlencoded, multipart/form-data, 或text/plain）。
- 请求包含自定义头部字段。
预检请求用于确认服务器是否允许该跨域请求。一旦预检请求成功，实际的请求才会被发送。

7. 安全性考量

限制允许的源：避免使用通配符*，而应该明确列出允许的源，以提高安全性。
使用HTTPS：跨域请求最好通过HTTPS进行，因为HTTP明文传输可能会导致数据泄露。
凭证管理：如果使用Access-Control-Allow-Credentials: true，确保只允许可信的源发送带有凭证的请求。

8. 测试和调试

使用开发者工具：大多数现代浏览器都有开发者工具，其中的Network面板可以查看HTTP请求的详细信息，包括请求头和响应头，这对于调试跨域问题是很有帮助的。
模拟不同的源：测试跨域请求时，可以使用不同的域名或子域来模拟跨域请求场景。

9. 其他解决方案

JSONP (JSON with Padding)：一种绕过同源策略限制的方法，适用于GET请求。但是存在安全风险，不推荐使用。
- 注入攻击：如果服务器没有正确验证callback参数，恶意脚本可以注入到<script>标签中，从而执行任意代码。
- 数据泄露：JSONP请求只能使用GET方法，这意味着所有请求参数都是可见的。如果请求中包含了敏感信息，这些信息可能会被第三方截获。
- XSS (Cross-Site Scripting)：如果服务器不正确地过滤回调函数名，恶意脚本可以通过构造恶意请求来触发XSS攻击。
- CSRF (Cross-Site Request Forgery)：虽然JSONP本身不会直接导致CSRF攻击，但如果一个站点允许JSONP请求并且没有适当的保护措施，那么攻击者可以构造恶意链接，诱使用户点击，从而触发未经用户授权的操作。
WebSocket：WebSocket协议本身不受同源策略限制，因此可以作为一种替代方案。
- 握手阶段：WebSocket连接的建立始于一个升级请求，从HTTP升级到WebSocket协议。在握手阶段，客户端发送一个特殊的HTTP请求，服务器响应确认，然后连接升级到WebSocket。
- 跨域支持：WebSocket规范允许跨域连接，只要服务器接受来自任何源的连接。服务器可以通过在握手响应中包含Origin头来决定是否接受连接。
- 安全性：WebSocket连接通常使用TLS/SSL（即wss://）来加密通信，这增加了安全性。安全的WebSocket连接提供了额外的保护，防止数据被监听或篡改。
- 设计初衷：WebSocket协议旨在提供实时通信能力，因此它被设计为不受同源策略的限制。由于其设计目标，WebSocket需要能够跨越多个域进行通信。

10. 最佳实践

最小化暴露：尽量减少跨域资源共享的范围，只暴露必要的API端点。
定期审查：定期审查跨域策略，确保它们符合最新的安全标准。
文档清晰：确保跨域策略在文档中有明确说明，便于开发者理解如何使用API。

结论

选择正确的技术来处理跨域请求非常重要，同时也要考虑到安全性和性能。

漆黑的莫莫

关注

20
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
Web跨域问题

当两个资源（如网页与API服务）位于不同的域名、协议或端口时，浏览器出于安全原因会阻止这些资源之间的交互。：一种机制，允许服务器明确指定哪些来源可以访问其资源。预检请求用于确认服务器是否允许该跨域请求。一旦预检请求成功，实际的请求才会被发送。：一种绕过同源策略限制的方法，适用于GET请求。选择正确的技术来处理跨域请求非常重要，同时也要考虑到安全性和性能。: 指定允许跨域请求的源。: 规定了预检请求（OPTIONS请求）的有效期，单位是秒。: 允许客户端发送的自定义HTTP头部字段。
复制链接

扫一扫