前端 vs 后端请求：核心差异与实战对比

1. 一句话速记

2. 四维原理对比（详细版）

3. 案例：登录 + 拉取并缓存天气

3.1 场景描述

1. 用户在前端输入账号密码登录。
2. 前端仅需要“上海”天气。
3. 后端为了后续推荐，需要静默把“北京、广州、深圳”天气写入 Redis 缓存。

3.2 时序图（Mermaid）

4、安全限制（Security Boundaries）

1. 底层原理：同源策略 Same-Origin Policy（SOP）
   • 定义：scheme + host + port 三元组完全一致才视为同源。
   • 作用域：DOM 访问、Cookie、LocalStorage、IndexedDB、fetch/XHR、WebSocket。
   • 设计目标：防止恶意站点读取其他站点的敏感数据（而不是阻止发请求）。

2. 浏览器实际行为
   ┌─────────────┬──────────────┬──────────────┐
   │ 场景 │ 请求能否发出 │ 响应能否被 JS 读取 │
   ├─────────────┼──────────────┼──────────────┤
   │ 简单 CORS │ ✅ │ ✅（需 ACAO 头） │
   │ 带预检 CORS │ ✅（两次） │ ✅（需 ACAC 头） │
   │ no-cors │ ✅ │ ❌（opaque） │
   └─────────────┴──────────────┴──────────────┘

3. 攻防视角
   • CSRF：利用“请求能发出去”的特点，让浏览器携带 Cookie 完成敏感操作。
   防护：SameSite=Lax/Strict、双重 Cookie、Token 在 Header。
   • XSS + SOP 绕过：通过 <script src> / <img> 标签天然不受 SOP 限制，窃取 JSONP 响应。
   • Spectre / 侧信道：借助高精度计时器读取跨源渲染像素 → 浏览器降低 SharedArrayBuffer 精度、COEP/COOP。

4. 调试技巧
   • 浏览器 DevTools → Network → 查看 Access-Control-Allow-Origin 与预检 OPTIONS。
   • chrome://flags/#disable-web-security 可临时关闭 SOP（仅本地调试）。
   • curl -H "Origin: http://evil.com" 快速验证后端 CORS 配置。

================================================================

5、身份凭证（Identity Credentials）

浏览器与服务器在“谁能带什么、怎么带”上截然不同，可用下图概括：

浏览器：Cookie（自动）  └─ SameSite、Secure、HttpOnly  JWT / Token（手动放到 Header/Body）  
服务器：任意 HTTP Header（Authorization、X-Api-Key）  mTLS 双向证书  私网协议（Redis AUTH、MySQL 用户名密码、SSH Key 等）

5.1. Cookie 全景

• 属性速查表
Set-Cookie: sessionId=abc; Path=/; Domain=.foo.com; Secure; HttpOnly; SameSite=Lax; Max-Age=3600
• 生命周期
① 浏览器收到响应头 → 写入 Cookie 仓库
② 后续同源请求自动带 Cookie: 头
③ JS 无法读取 HttpOnly Cookie，可缓解 XSS 盗取。

• SameSite 行为矩阵
SameSite=Strict 仅同站导航携带 SameSite=Lax 顶级导航 GET 可带（默认 2022+） SameSite=None 任意跨站都带，必须 Secure

• 典型攻击
- CSRF：跨站 POST 自动带 Cookie → 后端需 Token 二次校验。
- 会话固定：登录前把 Cookie 注入到浏览器 → 登录后劫持会话。

5.2. Token / JWT

• 存储位置
- WebStorage（localStorage/sessionStorage）：易受 XSS 窃取。
- Cookie（双 Cookie）：防 XSS，但仍需防 CSRF。
- Memory：SPA 单页刷新丢失，需配合 refresh_token。
• 传输位置
- Authorization: Bearer <jwt>（前端手动）
- 或签在 Cookie 里（前端不碰，后端解析）。

5.3. 服务器端凭证

• Service-to-Service Token（OAuth2 Client Credentials Grant）
• mTLS：客户端证书自动带在 TLS 握手，无需应用层处理。
• 连接池复用：后端可长期保存数据库密码、Redis AUTH，浏览器做不到。

5.4. 调试 & 审计

• 浏览器：Application → Cookies → 查看属性 & 是否 HttpOnly。
• 后端：
curl -H "Authorization: Bearer $TOKEN" \ -H "Cookie: sessionId=abc" \ https://api.foo.com/user
• 日志：记录 X-Forwarded-For、User-Agent、Authorization 前缀（脱敏后）。

一句话总结

• 浏览器只能在“同源沙箱”里玩，携带的凭证要么 Cookie（自动），要么手动塞 Token；
• 服务器处于“网络终端”，想发什么协议就发什么协议，想带什么凭证就带什么凭证，但必须自己做好鉴权、加密、审计。

5.6 Cookie和Token对比

5.7 Cookie、localStorage和sessionStorage对比