防止XSS攻击的Cookie设置技巧

本文深入解析了如何通过合理配置 Cookie 的 HttpOnly 和 Secure 属性来有效遏制 XSS 攻击后的关键危害——会话 Cookie 窃取，强调二者必须协同启用（并推荐叠加 SameSite 限制），才能同时阻断 JavaScript 脚本读取和网络层明文截获；文章不仅提供主流语言的设置示例，更厘清了常见误区：HttpOnly 并非 XSS 防御终点，而只是纵深防御中至关重要的一环，真正的安全还需结合输入过滤、输出编码、CSP、二次验证等多层手段共同构建。

HttpOnly 和 Secure 是 Cookie 的两个关键安全属性，它们不能阻止 XSS 攻击本身，但能显著限制 XSS 成功后的危害——尤其是防止攻击者窃取会话 Cookie。

HttpOnly：阻断 JavaScript 读取敏感 Cookie

启用 HttpOnly 后，浏览器禁止 JavaScript（包括 document.cookie、XMLHttpRequest、Fetch）访问该 Cookie。即使页面存在 XSS 漏洞，攻击者注入的脚本也无法通过 document.cookie 获取到带此属性的 Cookie（如 sessionid）。

注意：HttpOnly 只影响“读取”，Cookie 仍会在后续请求中由浏览器自动携带发送给服务端，不影响正常登录态维持。

• 后端设置示例（Node.js/Express）：
  res.cookie('sessionid', 'abc123', { httpOnly: true, secure: true, sameSite: 'lax' });
• PHP 示例：
  setcookie('sessionid', 'abc123', [ 'httponly' => true, 'secure' => true, 'samesite' => 'Lax' ])
• 务必为所有含认证信息的 Cookie（如 session、auth_token）启用 HttpOnly

Secure：确保 Cookie 仅通过 HTTPS 传输

Secure 属性强制浏览器只在 HTTPS 协议下发送该 Cookie。这可防止 Cookie 在 HTTP 明文传输中被中间人（MITM）窃听或劫持。

⚠️ 若未启用 Secure，而网站支持 HTTP 访问（或用户手动输入 http://），浏览器可能在非加密连接中发送 Cookie，导致凭据泄露。

• 只有部署了有效 TLS 证书、全站强制 HTTPS 的站点才应启用 Secure
• 开发环境若无 HTTPS，可暂时关闭 Secure（但上线前必须开启）
• 配合 HSTS 头使用效果更佳，可进一步防止协议降级攻击

两者配合才能发挥最大防护效果

单独启用 HttpOnly 而不启用 Secure，Cookie 仍可能在 HTTP 请求中被截获；单独启用 Secure 而不启用 HttpOnly，XSS 仍可盗取 Cookie 内容。二者是互补机制：

• HttpOnly → 防前端脚本窃取
• Secure → 防网络层窃取
• 建议始终同时设置：HttpOnly + Secure + SameSite
• SameSite（推荐设为 Lax 或 Strict）还能额外缓解 CSRF，属于协同加固项

需要澄清的常见误区

HttpOnly 不是 XSS 防御的“银弹”。它无法阻止 XSS 发生，也不能防御 DOM 型 XSS 对其他数据的篡改（比如篡改页面内容、发起恶意请求、记录键盘输入等）。它只保护 Cookie 不被 JS 读取。

• XSS 防御仍需多层：输入过滤、输出编码、CSP 策略、框架自带转义机制
• 敏感操作（如转账、密码修改）应引入二次验证，不依赖 Cookie 单一凭证
• 定期清理长期有效的 Cookie，缩短会话生命周期，降低被盗后的利用窗口

今天带大家了解了的相关知识，希望对你有所帮助；关于文章的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~