RESTful API中敏感数据customerId能否放在URL传递及最优方案咨询

结论先行 #

敏感的customerId绝对不建议直接放在GET请求的URL中传递，存在极高的泄露风险。

为什么不能放URL里 #

核心风险点如下：

• 所有中间节点都会默认留存URL记录：浏览器历史、Web服务器访问日志、代理/CDN日志、企业流量审计系统都会完整存储URL全路径，明文敏感ID相当于全程裸奔，只要任意一个环节的日志泄露，所有用户ID都会被批量获取
• 额外泄露场景多：用户手动分享URL、浏览器自动补全、页面跳转时的Referer头携带、搜索引擎爬虫抓取等场景，都可能意外泄露用户的customerId
• 就算用HTTPS，传输过程中URL是加密的，但落地到各个节点的日志里还是明文，一样有风险

最优实现方案 #

根据你的接口场景二选一即可：

场景1：必须保留GET方法（需要缓存、需要支持前端直接跳转、要求资源查询幂等）

优先选两种实现：

• 把customerId移到自定义请求头中传递：比如新增X-Auth-Customer-Id请求头，服务端统一从请求头取值，同时配置所有日志系统对该请求头做脱敏处理，默认的访问日志不会记录自定义请求头内容，避免泄露
• 若必须在URL里带标识：用一次性临时token替换明文ID，生成带过期时间（比如5分钟内有效）、不可逆向解密的单次有效token，路径改为GET /customers/{temp_customer_token}，服务端拿到token后校验合法性再映射到真实的customerId，就算token泄露也不会暴露原始ID，且过期后无法复用

场景2：无强制GET要求

直接改用POST方法，把customerId放在JSON请求体中传递，POST请求的请求体不会被常规日志、代理节点默认记录，泄露风险远低于URL传参，同时接口走HTTPS加密即可满足安全要求。

额外通用安全要求 #

不管用哪种方案，都要做两层校验：

• 接口必须加权限校验，验证当前请求的登录态是否有权限查询该customerId对应的客户信息，避免越权访问
• 所有内部日志（应用日志、中间件日志、服务器日志）必须对customerId这类敏感字段做脱敏处理，避免内部日志泄露导致数据外流

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