浏览器 Web 安全基础系列

  1. 浏览器怎么判断是不是同一个网站

  2. Cookie 为什么会自动携带

  3. Session 登录状态为什么可能被劫持

  4. HTTPS 为什么仍然不够（当前篇）

  5. CORS 到底在限制什么

  6. CSRF 是怎么冒用登录状态的

  7. CSRF 如何防御

  8. XSS 为什么能在你的网站执行

  9. CSP 与浏览器安全响应头

  10. Clickjacking 点击劫持

  11. 第三方资源为什么危险

  12. 防盗链到底防什么

HTTPS 不是“网址前多了一个 s”，而是浏览器与服务器通过 TLS 建立加密和身份认证通道。它保护传输中的 Cookie、密码和响应内容，降低窃听与篡改风险。但仅配置证书还不够，还要处理 HTTP 入口、Secure Cookie 和混合内容。

HTTPS 与 HSTS 访问流程

HTTPS 主要解决三个问题

  1. 机密性：中间网络无法直接读出请求和响应正文。

  2. 完整性：传输内容被修改时，连接校验会失败。

  3. 服务器身份认证：浏览器通过证书链确认正在连接的域名。

HTTPS 不会自动修复 XSS、CSRF、越权和 SQL 注入。它保护的是传输通道，而不是应用业务逻辑。

301 跳转仍有首次 HTTP 请求

常见配置：

http://example.com
→ 301 https://example.com

问题是用户第一次输入 HTTP 地址时，请求已经通过明文网络发出。中间人可能在浏览器收到 301 前篡改响应。

HSTS 响应头告诉浏览器：未来一段时间内，这个域名只允许 HTTPS：

Strict-Transport-Security: max-age=31536000; includeSubDomains

浏览器保存策略后，即使用户输入 http://，也会在网络请求前升级为 HTTPS。

Node.js 示例：

app.use((req, res, next) => {
  res.setHeader(
    'Strict-Transport-Security',
    'max-age=31536000; includeSubDomains'
  );
  next();
});

HSTS 只有通过 HTTPS 响应收到时才可信。HSTS Preload 可以进一步处理首次访问，但加入前必须确认整个域名及子域名长期支持 HTTPS，退出预加载列表也不是即时生效。

登录 Cookie 应设置：

Secure

它阻止浏览器通过普通 HTTP 发送 Cookie。但 Secure 不是加密 Cookie 内容，也不能替代 HTTPS。Cookie 值仍可能在客户端存储中可见，服务端不要把密码等敏感明文直接放进 Cookie。

混合内容

HTTPS 页面加载 HTTP 资源称为混合内容：

<script src="http://cdn.example.com/app.js"></script>

如果脚本通过 HTTP 加载，中间人可以替换脚本，进而控制整个 HTTPS 页面。浏览器通常会阻止这类“主动混合内容”。

混合内容风险

图片、音频等某些资源可能被自动升级或限制，但不应依赖浏览器兜底。项目中应统一使用 HTTPS 或相对协议无关的站内路径：

<script src="https://cdn.example.com/app.js"></script>
<img src="/images/banner.webp" alt="">

反向代理下的 HTTPS 判断

Node.js 服务部署在 Nginx、CDN 或负载均衡器后时，应用与代理之间可能是 HTTP，但用户侧是 HTTPS。需要正确配置可信代理，避免错误重定向或错误生成 Cookie：

app.set('trust proxy', 1);

app.use((req, res, next) => {
  if (!req.secure) {
    return res.redirect(308, `https://${req.headers.host}${req.url}`);
  }
  next();
});

trust proxy 不能盲目开启，必须与真实代理拓扑匹配，否则攻击者可能伪造转发头。

开发环境证书

本地 HTTPS 实验可以使用自签名证书。浏览器会提示证书不受信任，这是因为它不在系统信任链中，不代表 TLS 加密完全没有发生。生产环境必须使用受信任 CA 签发、域名匹配且未过期的证书。

常见误区

有 HTTPS 就不用 HttpOnly 和 SameSite

不对。HTTPS 防网络窃听；HttpOnly 防 JavaScript 直接读 Cookie；SameSite 限制跨站携带。它们保护不同层面。

所有内容都加密，所以日志里也安全

TLS 只保护网络链路。服务端、代理、APM 和访问日志仍可能记录查询参数、请求头和正文，敏感信息不要放进 URL。

HSTS 可以防所有中间人攻击

HSTS 主要强制 HTTPS，前提是证书体系和终端环境可信；它不能修复应用代码漏洞。

小结

生产 Web 应用至少应做到：全站 HTTPS、HTTP 重定向、登录 Cookie 使用 Secure、逐步启用 HSTS、清理混合内容，并正确处理反向代理。TLS 是其他安全机制成立的底座，但不是完整的应用安全方案。

参考资料