Session ID 放在 URL 中极不安全，会因浏览器历史、服务器日志、代理缓存和用户误分享导致明文泄露，且无法防 XSS、无法绑定客户端、无法主动失效，易被窃取并用于越权访问。
Session ID 放在 URL 中，本质上是把会话凭证“写在明信片上寄出去”——谁都能看见、能复制、能转发。它绕过了浏览器对 Cookie 的安全管控机制，直接暴露在多个不可控环节中。
URL 泄露的四大高危场景
会话标识一旦嵌入 URL，就会随用户操作被动扩散，且难以清理：
-
浏览器历史记录：用户访问
https://site.com/home?sessionid=abc123后，该完整 URL 会被存入历史，他人使用同一设备即可翻看 - 服务器访问日志：Nginx/Apache 默认记录完整请求路径，日志中长期留存大量有效 sessionid，一旦日志泄露或被未授权人员访问，会话可批量盗用
- 代理与中间设备缓存：HTTP 代理、CDN、ISP 设备可能缓存带 sessionid 的响应，或在调试/监控中记录原始请求，形成隐蔽泄露面
- 用户误分享行为：用户点击“复制链接”分享页面时，无意中把含 sessionid 的 URL 发给同事、发到社交平台，甚至粘贴进邮件或工单系统
越权风险：URL 不具备身份绑定与自动失效能力
Cookie 可通过 HttpOnly、Secure、SameSite 等属性实现精细控制；而 URL 中的 sessionid 完全无此能力：
-
无法防止 XSS 直接窃取：JavaScript 可轻松读取
window.location.href并提取 sessionid，再通过 fetch 发送给攻击者服务器 - 无法限制传输通道：即使网站已启用 HTTPS，用户若从带 sessionid 的 URL 点击跳转到 HTTP 页面（如旧书签、错误重定向），该 ID 仍会以明文发出
- 无法绑定客户端特征：服务端无法校验该 URL 请求是否来自原登录设备的 IP、User-Agent 或 TLS 指纹，攻击者截获后可在任意终端复用
- 无法支持主动失效：用户登出时，服务端可销毁 session，但 URL 中的 sessionid 仍有效——只要没过期，任何人拿着链接就能继续访问
真实攻击链示例：一次分享引发的账户接管
某后台系统为兼容老旧浏览器启用了 URL 重写：https://admin.example.com/dashboard?JSESSIONID=7f8a9b2c1d4e5f6
- 管理员将该链接复制进内部 IM 工具发给同事协助排查
- IM 工具将链接自动渲染为可点击卡片，并缓存预览图（含完整 URL）
- 该 IM 账号因弱口令被撞库，攻击者下载聊天记录，提取出有效 JSESSIONID
- 攻击者用该 ID 直接访问后台接口，导出全部用户手机号与订单数据
整个过程未触发任何登录验证，也未留下异常登录日志——因为会话本就是合法的，只是被错误地“共享”了。
