银行、保险、医疗、人力资源这些业务一旦通过 SAP Gateway 暴露成 OData 服务，很容易遇到一个看似普通、实际很棘手的问题。业务查询需要传入银行卡号、员工编号、证件号码、客户账户等条件，而 OData 又习惯把查询条件表达在 URL 里。于是，一条功能上完全正确的请求，很可能变成下面这种形式。https://odata.example.org/OData/Banking.svc/CreditCards?$filter=CardNumber eq '1234 5432 1234 6543'从 OData 语义看没有问题，从网络传输角度看，只要使用 HTTPS，HTTP 请求内容也处于 TLS 保护之下。SAP Gateway 官方安全文档同样明确指出，OData URL 中可能包含敏感数据，并假定通信使用 HTTPS 进行保护。可真正做企业级接口设计时，仅仅看到https就认为安全问题已经结束，风险会被严重低估。原因在于 URL 并不只存在于网络链路上。它可能进入浏览器历史记录、Web Server Access Log、Reverse Proxy 日志、API Gateway 日志、APM Trace、前端诊断信息，也可能在特定条件下参与Referer传播。HTTPS 解决的是链路中的机密性和完整性，它不会自动替应用服务器清理日志，更不会自动阻止浏览器保存访问记录。这也是 SAP Gateway 为什么专门提出一条非常实际的设计建议，不要把秘密数据或者敏感数据设计成 OData Entity 的 Key。对于无法避免出