核心是验证响应头set-cookie是否含secure、httponly、samesite三属性，且samesite=none时必须配secure；需抓包确认https下cookie正常发送、http下不发送，并排除反代或前端降级导致的失效。
直接检查 Cookie 是否存在明文传输敏感凭证隐患，核心不是看 JavaScript 怎么写 document.cookie，而是验证它是否真正受 Secure + HttpOnly + SameSite 三重约束保护，并确认整条链路未被降级。浏览器不认 JS 字符串里的 Secure，只认服务端 Set-Cookie 响应头里声明的标志。
查响应头中的 Set-Cookie 字段是否含 Secure 和 HttpOnly
打开浏览器开发者工具 → Network → 找到登录或鉴权成功后的响应（如 /login 或 /api/auth）→ 查看 Response Headers → 定位 Set-Cookie 行：
- ✅ 合规示例：
Set-Cookie: sessionid=abc123; Path=/; Secure; HttpOnly; SameSite=Lax - ❌ 风险示例：
Set-Cookie: token=xyz; Path=/（缺 Secure、HttpOnly、SameSite） - ⚠️ 注意：多个 Cookie 要逐个检查；若使用了
SameSite=None，必须同时带Secure，否则现代浏览器直接丢弃
抓包验证 HTTPS 下是否真发送了带 Secure 的 Cookie
用 Burp Suite 或 Charles 抓包，重点观察两个环节：
- 页面加载后发起的后续请求（如 AJAX、图片、iframe），其 Request Headers 中是否包含该 Cookie
- 切换到 HTTP 页面（如手动改地址栏为
http://yoursite.com），再发相同请求 → 此时 Cookie 不应出现在请求头中（验证 Secure 生效） - 若在 HTTP 页面仍能发出去，说明要么没设 Secure，要么服务端误配（如反代未透传 X-Forwarded-Proto）
检查前端是否无意破坏安全前提
即使后端配对了，前端操作也可能让 Secure 失效：
- 表单
<form action="http://..."></form>或跳转链接写死http://→ 触发混合内容，浏览器可能阻止或清空 Secure Cookie - JS 中用
fetch('http://api.example.com')请求非 HTTPS 接口 → 该请求不会携带 Secure Cookie，且可能被劫持 - 资源（JS/CSS/字体）通过 HTTP 加载 → Chrome 等会标记为“不安全”，部分版本会禁用 Cookie 发送
确认本地开发与生产环境一致性
开发常用 http://localhost，但要注意：
-
http://localhost允许设置和发送 Secure Cookie（浏览器特例），但http://127.0.0.1不允许 → 若本地测试混用两者，易误判安全性 - 上线前必须确保：全站强制 HTTPS、Nginx/CDN 开启 HSTS、后端开启
SECURE_SSL_REDIRECT类配置 - 审计时需以真实生产 URL（
https://）为准，避免被 localhost 的宽容行为误导
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
