GET请求中传递Login token是否合规？技术安全性咨询

这种通过GET请求URL传递登录token的方案存在严重安全风险，不建议采用，具体风险和原因如下：

核心风险点 #

• 全链路日志泄露：GET请求的完整URL会被浏览器、应用服务器、反向代理、CDN等多个环节记录到日志文件中。token作为能直接登录指定用户的敏感凭证，一旦日志被未授权访问或泄露，攻击者可直接利用token冒充目标用户登录系统。
• 浏览器端泄露隐患：浏览器会保存URL历史记录，token会被持久化到本地；同时浏览器缓存、第三方插件也可能捕获到包含token的URL，甚至用户在复制、分享页面时会意外把带token的URL扩散出去，导致凭证外泄。
• CSRF攻击风险：若token未做严格校验（比如绑定请求IP、限制单次使用、设置极短有效期），攻击者可构造包含该token的恶意链接，诱导拥有管理后台权限的用户点击，从而以指定用户身份执行未授权操作。

为什么POST请求更安全 #

POST请求的参数会放在请求体中，不会暴露在URL里，能避免上述日志、历史记录、缓存等场景下的token泄露问题，是传递敏感凭证的标准安全做法。

优化建议 #

• 将登录请求改为POST方式，把token放在请求体中传递；
• 给token添加严格限制：设置10秒以内的极短有效期、绑定请求发起的客户端IP、限制token只能使用一次；
• 对管理后台的“以用户身份打开”功能做更严格的权限管控，仅开放给超级管理员，同时记录每一次操作的详细日志（操作人、目标用户、时间等），便于事后审计。

内容的提问来源于stack exchange，提问作者user3421673