使用自定义Header在GET请求中传输参数是否符合安全规范？

先直接给结论：这种传输方式是否可行，完全取决于你要传的数据类型和场景——非敏感数据在HTTPS加持下可以临时用，但敏感数据绝对不能这么做，具体风险和注意事项如下：

• 日志泄露风险是核心问题
  几乎所有Web服务器、反向代理都会把请求头信息记录到日志里。如果你的Costum_Data_1/2是敏感内容（比如用户token、隐私数据、业务密钥），这些数据会以明文形式留在日志文件中，不管是运维人员误查看，还是日志被攻击者窃取，都会直接导致数据泄露。

• 缓存与历史记录的潜在隐患
  GET请求本身会被浏览器、代理服务器缓存，虽然请求头一般不在缓存的键值里，但一些老旧的缓存系统或者异常配置可能会把请求头纳入缓存范围；另外，浏览器的请求历史相关元数据如果被恶意脚本利用漏洞读取，也存在间接泄露请求头数据的可能。

• 和POST请求的安全差异
  很多人以为POST比GET安全，核心原因不是传输过程的加密（HTTPS下两者的请求内容都会被加密），而是POST的请求体默认不会被服务器记录到日志里，而GET的请求头和URL参数都会被日志留存。所以用GET+请求头传数据，并没有解决GET请求本身的日志存储风险。

• 敏感数据的红线
  如果你的自定义数据是密码、会话token、用户手机号这类敏感信息，不管是放在GET的请求头还是URL参数里，都是严重的安全违规，必须改用POST（或PUT）请求，把数据放在请求体中，同时确保全程使用HTTPS。

• 非敏感数据的使用前提
  如果只是传递一些无风险的标识（比如客户端版本号、非敏感的设备ID），在HTTPS加密传输的前提下，这种方式不会有传输过程中的泄露风险，但一定要提前确认服务器和代理的日志策略，配置禁止记录这些自定义请求头，避免数据被意外留存。

总结建议 #

优先遵循Web开发的标准实践：用POST请求将数据放在请求体中，这能规避绝大多数日志、缓存带来的安全风险。如果因为业务限制必须用GET+请求头的方式，务必满足两个条件：数据绝对非敏感，且服务器/代理不记录这些自定义请求头。

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