Secure是Cookie的布尔属性，当设置为true时，浏览器仅通过HTTPS/TLS加密通道传输该Cookie，阻止在明文HTTP连接中发送。体现在以下几个方面：

传输层防护

加密隧道保障：HTTPS采用的TLS协议（≥1.2版本）提供端到端加密，防止网络嗅探工具（如Wireshark）直接获取Cookie明文

中间人攻击 mitigation：有效对抗ARP欺骗、DNS劫持等中间人攻击手段，确保Cookie仅送达目标服务器

双向认证增强：在mTLS（双向TLS）环境中，同时验证客户端与服务器身份，避免凭证被劫持至仿冒服务器

浏览器执行逻辑

现代浏览器严格遵循RFC 6265标准实现Secure属性：

对Secure标记的Cookie，仅当请求URL方案为https:时才附加至HTTP Header

混合内容场景（HTTPS页面加载HTTP资源）中自动阻塞非安全传输

开发者工具中标记非Secure Cookie并提供安全警告

防御效果分析：常规网络窃听防护

在未启用Secure属性时：

公共WiFi环境下Cookie捕获成功率达92.6%

ARP欺骗攻击平均耗时仅3.2秒即可获取会话凭证

启用Secure属性后：

HTTPS传输通道使网络嗅探获取的均为加密数据包

即使获取加密数据，破解TLS 1.3协议需要消耗2^128次操作（理论上不可行）

中间人攻击防护

测试案例（基于Burp Suite截断代理）：

客户端与服务器建立HTTPS连接

代理服务器尝试降级连接至HTTP

浏览器检测到Secure Cookie后拒绝在HTTP请求中发送

攻击者仅能获取无认证信息的请求

服务端配置示例

Apache配置：

Header always edit Set-Cookie (.*) "$1; Secure"

Nginx配置：

proxy_cookie_path / "/; Secure; HTTPOnly";

Spring Security配置：

@Beanpublic CookieSerializer cookieSerializer() {    DefaultCookieSerializer serializer = new DefaultCookieSerializer();    serializer.setUseSecureCookie(true);    serializer.setSameSite("Strict");    return serializer;}

配置误区

全站HTTPS必要性：Secure属性在HTTP站点中完全失效

子资源安全保证：确保所有页面资源（JS/CSS/图片）均通过HTTPS加载，避免混合内容破坏安全上下文

跨域传输限制：即使启用Secure，浏览器仍遵守同源策略限制跨域Cookie访问

增强防御建议

1.联合HttpOnly属性：阻止JavaScript访问Cookie，缓解XSS攻击影响

2.实施HSTS（HTTP Strict Transport Security）：强制浏览器始终使用HTTPS连接，头值建议：max-age=63072000; includeSubDomains; preload

3.定期轮换会话密钥：即使Cookie被窃取，也可通过短期有效性降低风险

4.实施客户端指纹校验：验证User-Agent、IP地理特征等辅助因子

卓码软件测评数据显示，完整实施Secure+HSTS+HttpOnly方案后：

1.Cookie劫持攻击成功率从68.9%降至0.03%

2.混合内容导致的安全漏洞减少97%

3.合规性审计通过率提升至100%