后端开发Cookie安全配置防护风险

后端开发中Cookie安全配置的失当，往往比SQL注入或XSS更隐蔽，因为它不直接破坏服务端逻辑，却能把用户身份、会话令牌甚至权限边界撕开一道口子。很多开发者只关注Set-Cookie里写了什么值，却忽略了属性组合、作用域、生命周期和加密策略之间的联动关系。一个没有HttpOnly的会话Cookie配合一个反射型XSS，等于把账号控制权直接递给攻击者；一个缺失SameSite的Cookie在跨站请求中会被浏览器自动携带，让CSRF防护形同虚设。真正的问题不是“要不要配置”，而是“在什么业务场景下配置到什么强度”，以及“配置之后如何验证它真的生效”。

HttpOnly的作用是禁止JavaScript通过document.cookie读取Cookie。这个属性不能阻止XSS的发生，但能显著降低XSS的杀伤半径。后端在签发会话标识时，必须显式设置HttpOnly。很多框架默认不开启，例如某些版本的Express在res.cookie中需要手动写httpOnly: true。实际部署中，应当对包含身份信息、令牌、用户偏好之外的任何敏感数据一律启用HttpOnly。需要前端读取的Cookie，例如主题偏好、语言设置，可以单独拆分成非敏感的客户端可读Cookie，与会话Cookie隔离。不要为了一个前端功能把整个会话Cookie暴露给脚本。

Secure属性告诉浏览器只在HTTPS连接中发送该Cookie。如果站点仍然允许HTTP访问，或者存在HTTP到HTTPS的跳转链路，攻击者可以通过中间人方式在HTTP请求中截获Cookie。后端应当强制全站HTTPS，并在Set-Cookie中带上Secure。仅配置HSTS还不够，因为HSTS只解决浏览器策略问题，Cookie本身的安全标记才是最后一道防线。开发环境中经常因为本地HTTP调试而省略Secure，这会导致测试环境与生产环境配置不一致，最终上线时遗漏。建议通过环境变量控制，但生产环境必须硬编码开启。

SameSite有三个值：Strict、Lax、None。Strict模式下，浏览器在任何跨站请求中都不发送该Cookie，包括用户从外部链接点击进入站点时的顶级导航。Lax模式允许顶级导航携带Cookie，但阻止POST、iframe、AJAX等跨站子请求携带。None模式则完全放开，但必须同时设置Secure。对于普通的会话Cookie，Lax是平衡安全与可用性的默认选择。对于处理敏感操作、支付、后台管理的接口，如果业务允许，应当使用Strict。需要特别注意，第三方登录回调、OAuth流程、支付回调等场景如果依赖跨站POST携带Cookie，SameSite=None是必需的，但此时必须配合CSRF Token和来源校验，否则等于把门打开。

Domain属性决定Cookie在哪些主机上有效。如果不设置Domain，Cookie默认仅对当前主机有效，不包含子域。很多开发者为了让api.example.com和www.example.com共享会话，会设置Domain=example.com。这本身没问题，但必须清楚这意味着任何example.com的子域都能收到该Cookie。如果某个子域存在漏洞或被入侵，攻击者可以在该子域上读取或滥用这个Cookie。更危险的是，如果设置了过宽的Domain，例如.com或.co，浏览器会直接拒绝，但一些中间件或自定义响应头可能绕过校验。Path属性则限制Cookie在指定路径下发送。将敏感Cookie的Path设置为最小必要路径，例如/admin或/api，可以减少无关页面携带敏感Cookie的机会。但要注意，Path不是安全边界，它只是减少暴露面，不能依赖它做访问控制。

会话固定攻击的核心是攻击者先获得一个有效的会话ID，然后诱骗受害者使用该会话ID登录。登录成功后，攻击者即可利用同一个会话ID冒充受害者。后端必须在用户登录成功后立即轮换会话ID，旧会话ID必须失效。很多框架提供了session.regenerate()方法，但开发者经常忘记在权限提升、密码修改、二次验证通过等关键节点调用。轮换会话ID时，要确保新的Cookie通过Set-Cookie正确下发，并且旧Cookie在服务端存储中被彻底删除。对于分布式会话存储，删除操作必须同步到所有节点，否则旧会话ID在部分节点上仍然有效。

有些后端会把用户ID、角色等信息直接编码进Cookie，例如Base64编码的JSON。Base64只是编码，不是加密，任何人都能解码并篡改。如果Cookie中必须携带服务端需要读取的数据，应当使用签名机制，例如HMAC-SHA256对Cookie值进行签名，并将签名作为Cookie的一部分或单独一个Cookie下发。服务端在读取时验证签名，防止篡改。对于机密数据，应当使用加密，例如AES-GCM，密钥只保存在服务端。签名和加密的密钥必须通过环境变量或密钥管理服务注入，不能硬编码在代码仓库中。密钥轮换策略也要提前设计，否则一旦密钥泄露，所有历史Cookie都可能被伪造。

现代浏览器支持Cookie名称前缀，这是一种额外的安全约束。__Host-前缀要求Cookie必须同时设置Secure、Path=/、且不能设置Domain属性，也就是说它只能绑定在单一主机上。__Secure-前缀要求Cookie必须设置Secure，但允许设置Domain和Path。使用这些前缀可以防止子域覆盖或非安全连接下的Cookie注入。例如，将会话Cookie命名为__Host-session，即使某个子域存在XSS，也无法通过设置同名Cookie来覆盖主站的会话，因为子域无法满足__Host-前缀的Domain限制。这是一种低成本高收益的防护手段，尤其适合对会话Cookie进行加固。

Cookie值经常出现在服务端访问日志、错误日志、调试输出和监控系统中。如果日志系统记录了完整的请求头，Cookie中的会话ID、令牌就会以明文形式落盘。后端应当对日志进行脱敏，过滤Cookie头或至少对敏感Cookie值进行掩码。反向代理、负载均衡、CDN的日志同样需要检查。另外，应用异常堆栈中如果打印了请求对象，也可能包含Cookie。开发框架的调试模式在生产环境必须关闭。对于必须记录请求上下文的场景，应当使用结构化日志并明确排除敏感字段。

如果设置了Domain=example.com，而某个子域例如old.example.com已经不再使用，但其DNS记录仍然指向第三方平台或过期的主机，攻击者可能通过子域接管获得该子域的控制权。一旦控制子域，攻击者就能在该子域上接收example.com作用域的Cookie，并利用这些Cookie对主站发起会话劫持。企业应当定期审计所有子域的DNS解析和证书状态，及时清理不再使用的子域。对于需要共享会话的子域，尽量使用明确的子域列表，而不是通配符。如果业务允许，使用__Host-前缀可以彻底避免Domain作用域带来的子域风险。

配置了安全属性不代表它真的生效。后端应当在测试流程中加入Cookie安全扫描，检查Set-Cookie响应头中是否包含HttpOnly、Secure、SameSite等属性，并验证Domain和Path是否符合预期。可以使用自动化测试框架模拟登录流程，断言响应头中的Set-Cookie字段。对于生产环境，定期使用爬虫或安全扫描工具对所有入口进行检测。浏览器开发者工具中的Application面板可以直观查看Cookie属性，但人工检查无法覆盖所有路径。将Cookie安全检查集成到CI/CD流水线中，每次部署前自动执行，能有效防止配置回退。

后端开发对Cookie的防护不能停留在“设置几个属性”的层面。它涉及传输层安全、作用域设计、生命周期管理、加密签名、日志脱敏和自动化验证等多个环节。一个看似简单的Set-Cookie响应头，背后是攻击者与防御者围绕身份凭证的持续对抗。只有在每个环节都落实最小权限原则，并保持配置的一致性，才能把Cookie从攻击面转化为可信的身份载体。