验证客户端点：将邮编/姓氏放入查询字符串是否存在安全风险？

一、Query String存PII的真实风险 #

你担心的问题完全成立：

• 服务器日志、CDN日志、代理服务器日志都会完整记录query string，一旦日志泄露，攻击者可通过同一个客户ID的多次请求，将邮编和姓氏关联起来，直接定位到具体用户——单独的邮编或姓氏可能不算PII，但结合客户ID后就具备了个人识别能力，属于敏感数据范畴。
• 如果这个API面向前端页面调用，浏览器历史记录、书签甚至地址栏自动补全都会留存这些参数，用户共享设备时极易泄露信息。

二、GET vs POST的选择逻辑 #

主流API的差异本质是场景不同：

• Stripe、Shopify的搜索API大多供后端服务调用，这类场景下请求不会经过浏览器，日志也由服务方自主管控，风险可控；但如果你的API面向前端（比如用户在网页上提交验证），GET的风险会被放大。
• Salesforce用POST做搜索，核心原因是他们的搜索参数常包含更多敏感PII，同时也符合合规要求——多数数据保护法规要求敏感数据传输需避免明文出现在URL中。

关于REST规范的顾虑：别被教条束缚。REST的核心是「资源操作」，POST并非只能用于创建或搜索。当请求包含敏感数据时，用POST把参数放在请求体里是完全合理的选择。你的场景是验证客户有效性，本质是需要传递敏感数据的查询操作，用POST既规避了安全风险，也不违反REST的核心原则——规范是为服务于系统的安全性和可维护性，而非反过来。

三、具体建议 #

1. 优先采用POST：把邮编/姓氏、客户ID等参数放到请求体中，彻底避免query string带来的日志和历史记录问题。
2. 如果因技术限制必须用GET：
   • 对query string中的敏感字段（邮编、姓氏）进行加密，注意前端加密的密钥不能硬编码在代码里，最好通过接口动态获取。
   • 配置服务器日志策略，屏蔽query string中的敏感参数，避免日志留存PII。
   • 增加调用频率限制，防止攻击者通过批量请求关联数据。
3. 合规层面：明确这类组合数据属于可识别个人的信息，遵循所在地区的数据保护法规，比如数据最小化原则——只传递必要的验证字段，不要附带无关数据。

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