HTTPS 的查询字符串（Query String）安全吗
HTTPS 加密传输中的 URL 路径和查询参数，但浏览器、终止 TLS 的系统及日志仍可能保留它们。解释 Referrer-Policy、敏感参数处理和预签名 URL 风险。
一句话回答：HTTPS 会加密传输中的路径与查询参数，但终止 TLS 的系统、浏览器历史及日志仍可能保存它们。Referer 是否携带参数受 Referrer-Policy 和跳转关系影响。不要把密码或长期令牌放进 URL；请求体与 Header 也需日志脱敏和权限控制。预签名 URL 属于有时限、受控用途的凭据，不能当作公开链接。
传输层：加密覆盖
TLS 握手完成后才发送 HTTP 请求行（GET /path?key=value），所以：
- 运营商、公共 Wi-Fi、抓包者只能看到域名和流量特征
- 路径与参数是密文的一部分
落地层：这些地方会留下明文
| 位置 | 风险 |
|---|---|
| 浏览器历史记录 | 共享电脑/截图泄露 |
| 服务器访问日志（Nginx/Apache 默认记完整 URL） | 日志泄露=凭证泄露 |
| 反向代理/CDN 日志 | 多层留存 |
| APM/链路追踪的 URL 字段 | 监控系统里明文可查 |
| Referer 头 | 取决于 Referrer-Policy；现代默认跨源一般仅发源，同源或较宽松策略仍可能含路径和参数 |
| 用户复制分享链接 | token 随手发出去 |
常见泄露面包括 URL 的存储和传播；不能把传输加密等同于端到端保密。TLS 终止代理仍可看到明文请求。
正确做法
# ❌ 敏感信息放 query
GET /api/user?token=abc123
# ✅ token 放 Header
GET /api/user
Authorization: Bearer abc123
# ✅ 登录等敏感操作用 POST + body
POST /api/login
Content-Type: application/json
{"username": "...", "password": "..."}
query string 只放可公开的查询条件：页码、排序、筛选关键字。
已经有敏感参数进了日志怎么办
- 先阻止新增泄露：应用不再记录敏感参数；采集环节补充脱敏。观测云的本地 Pipeline可在 DataKit 上传前处理日志，用包含测试令牌的样本检查原始
message、URL 及派生字段，确认原文也已替换，而不只是提取出一个脱敏字段。 - 历史日志按泄露处理：访问控制 + 限期删除
- 泄露的 token 全部吊销重发
常见问题（FAQ）
Q：HTTPS 下 GET 请求的参数也会被加密，那表单 GET 提交密码为什么不行？
A：加密只保传输。GET 表单把密码写进 URL，于是浏览器历史、服务器日志、Referer 全都留痕——这就是登录表单一律 POST 的原因。
Q：预签名 URL（S3/OSS 下载链接）把签名放 query 里安全吗？
A：这是被设计为"URL 即凭证"的特例：短期有效，但持有者可使用，应按凭证保护而非公开传播。但注意它同样会进日志——有效期设短、按最小权限签发。
Q：API Key 到底放哪最合适？
A：遵循 API 的认证协议，Bearer token 通常用 Authorization 头；有些 API 使用 X-API-Key。两者没有固有安全排名，都需要 HTTPS、最小权限与日志脱敏。只读密钥同样不应公开放进 query。
参考资料
本文依据官方资料核对，未进行现场运行测试；代码与配置示例需结合实际版本、权限和环境验证。
- developer.mozilla.org：Referrer Policy
- www.rfc-editor.org：rfc6750
- docs.guance.com：pipeline
- docs.guance.com：logging
