跳到主要内容

网络基础、缓存策略与前端安全

🔐 前端网络优化和安全设计都发生在系统边界：理解协议、缓存和浏览器安全模型，才能避免“看似可用、实际脆弱”。

从 URL 到页面​

典型过程：

  1. 解析 URL 与检查缓存
  2. DNS 查询获得 IP
  3. 建立 TCP；HTTPS 还需 TLS 握手
  4. 发送 HTTP 请求
  5. 服务端或 CDN 返回响应
  6. 浏览器解析、加载子资源并渲染

HTTP/2 支持多路复用和头部压缩；HTTP/3 基于 QUIC，减少部分队头阻塞并改善连接迁移。

HTTP 缓存​

强缓存​

  • Cache-Control: max-age=...
  • immutable 表示有效期内资源不会变化
  • no-store 表示不存储
  • no-cache 表示可存储，但复用前必须验证

协商缓存​

  • ETag / If-None-Match
  • Last-Modified / If-Modified-Since

验证未变化时返回 304 Not Modified。

推荐缓存策略​

  • HTML：短缓存或 no-cache，确保可及时发现新版本。
  • 带内容 hash 的 JS / CSS / 图片：max-age=31536000, immutable。
  • API：根据数据时效、用户身份和写操作设计，避免机械缓存。
  • Service Worker：明确版本、更新、回退和离线策略。

Vary 会影响缓存键；私有用户数据不得被共享缓存错误复用。

CORS​

同源策略限制脚本读取跨源响应。CORS 由服务端通过响应头授权，而不是前端“关闭限制”。

常见头：

  • Access-Control-Allow-Origin
  • Access-Control-Allow-Methods
  • Access-Control-Allow-Headers
  • Access-Control-Allow-Credentials

携带凭据时不能使用通配符源，并需审慎校验允许的 Origin。

XSS​

攻击者将恶意脚本注入页面。

防护：

  • 默认转义不可信内容。
  • 避免直接使用 innerHTML；必须使用时进行可靠净化。
  • 富文本采用允许列表过滤。
  • 使用 CSP 限制脚本来源。
  • Cookie 设置 HttpOnly，降低脚本读取风险。

⚠️ 前端过滤不能替代服务端校验。数据可能从 API、历史存储、导入文件和协作消息等多条路径进入系统。

CSRF​

攻击者诱导已登录用户的浏览器向目标站点发送请求。

防护：

  • SameSite=Lax 或 Strict Cookie
  • CSRF Token
  • 校验 Origin / Referer
  • 修改操作使用正确 HTTP 方法，不使用 GET

其他风险​

  • 点击劫持：CSP frame-ancestors 或 X-Frame-Options。
  • 依赖供应链：锁定版本、审计依赖、减少安装脚本权限。
  • 开放重定向：校验跳转目标。
  • 敏感信息泄露：密钥不得进入前端 bundle、日志和 sourcemap。
  • 原型污染：谨慎合并不可信对象键。

请求可靠性​

  • 为请求设置超时和取消机制。
  • 仅对幂等操作自动重试，并使用退避与抖动。
  • 写操作考虑幂等键。
  • 区分网络错误、HTTP 错误和业务错误。

检查清单​

  • 静态资源采用内容 hash 与长期缓存
  • 用户数据不会被公共缓存
  • 富文本与 HTML 输入经过净化
  • Cookie 配置 Secure、HttpOnly、SameSite
  • CSP、CORS 和 CSRF 策略经过验证
  • 客户端代码和构建产物不包含密钥