检测未加密传输的高危会话 cookie，关键在于验证浏览器是否按规范加载和发送：检查 set-cookie 响应头含 secure、application 面板中 cookie 标记为 secure、http 请求不携带该 cookie，并结合扫描器日志定位具体 cookie 名称及修复方式。

前端安全扫描中检测未加密传输的高危会话 Cookie，关键不是靠 JavaScript 主动“检测”，而是验证浏览器是否按安全规范加载和发送 Cookie。JS 本身无法拦截或检查网络层传输过程，但可通过开发者工具、响应头分析和运行时状态判断其是否暴露在 HTTP 明文通道中。

看 Set-Cookie 响应头是否含 Secure

登录或会话初始化后，打开浏览器开发者工具 → Network → 找到返回 Set-Cookie 的请求（如 /login），点击查看 Response Headers：

• 确认 Set-Cookie 字段中明确包含 Secure（注意大小写不敏感，但必须是独立 token，不能拼错成 “secure=” 或漏空格）
• 若响应头中没有 Secure，即使页面是 HTTPS，该 Cookie 也会被浏览器允许通过后续 HTTP 请求发送——这就是扫描器报“Sensitive Cookie in HTTPS Session Without 'Secure' Attribute”的直接原因
• 特别注意：开发环境用 localhost 或 http:// 时，后端不应设 Secure；上线前必须确保生产环境响应头带 Secure

查 Application 面板确认 Cookie 标记为 Secure

切换到 Application → Cookies → 选择对应域名：

PigX UI 前端开发

PigX UI Pro 前端开发指南 - Vue 3 + TypeScript + Element Plus。当用户提到 PigX UI、PigX 前端、lgb-mgui 项目、Vue 3 企业级后台开发、Element Plus 后台开发时使用此技能。

下载

• 找到会话类 Cookie（如 sessionId、connect.sid、_session 等），观察其属性列
• Secure 列应显示为 ✅ 或锁形图标；若为空或标为 ❌，说明未生效
• 同时检查 HttpOnly 是否启用——若为 false 且值敏感（如含 token），则 XSS 下可被 document.cookie 读取，属双重风险

模拟 HTTP 请求验证是否意外携带

虽然现代浏览器禁止在 HTTP 页面设置 Secure Cookie，但仍需验证服务端是否“过度宽松”：

• 用 curl 或 Postman 发起纯 HTTP 请求（http://yourdomain.com/api/profile），观察请求头是否自动带上会话 Cookie
• 若带上，说明该 Cookie 缺少 Secure 属性，或服务端错误地在 HTTP 响应中下发了它
• 更严格的做法：在非 HTTPS 子域（如 http://test.yourdomain.com）访问，确认 Cookie 不出现——这能验证 Domain 和 Secure 的协同有效性

配合扫描器日志定位具体 Cookie 名称

常见安全扫描工具（如 Burp Suite、Nessus、Acunetix）报出的漏洞通常附带触发路径和 Cookie 名：

• 根据报告中的 Cookie 名称，在 Application 面板中精准定位，避免误判第三方统计 Cookie
• 若该 Cookie 由前端 JS 设置（如 document.cookie = "auth=xxx; path=/;"），立即改为后端 Set-Cookie 下发，并加上 Secure+HttpOnly
• 若扫描器提示“SameSite missing”，需补上 SameSite=Lax（登录类）或 SameSite=Strict（高敏操作），且 SameSite=None 必须配 Secure

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南