SAP Gateway 敏感数据防缓存设计，从 Cache-Control 到 DPC 运行时的安全边界

做 SAP Gateway 项目时，有一种安全问题很容易被忽略。OData 服务端的权限检查完全正确，HTTPS 也已经启用，用户退出 SAP Fiori Launchpad 之后 Session 也已经失效，看起来整个访问链路没有明显漏洞，但刚刚通过 ODataGET请求读取出来的员工信息、工资数据、银行账号、客户地址或者其他个人数据，却仍有可能停留在浏览器或者其他 User Agent 的缓存体系里。

这类问题和 ABAP 数据库权限不是同一个层面的问题。后台授权控制解决的是谁能够从 SAP 系统读取数据，而 HTTP 缓存控制解决的是数据离开 SAP Gateway 之后，User Agent 和中间缓存还能不能继续保存甚至重新使用这份数据。

SAP Gateway Foundation 对这件事情提供了非常明确的控制机制。当某个GET请求返回机密数据或者个人相关数据时，应用可以通过/IWBEP/IF_MGW_CONV_SRV_RUNTIME~SET_HEADER()设置 HTTP Response Header，通知 User Agent 不要缓存这些响应。SAP 官方文档明确要求，返回此类数据的GET方法应设置相应的Cache-ControlHeader。

这一点看起来只是一两行 ABAP，但真正理解之后，会发现它实际上跨越了 SAP Gateway Runtime、OData、HTTP Cache、浏览器、安全设计和 Clean Core 几个层面。

我们可以从一个很常见的企业场景切进去。

假设公司有一个 SAP Fiori 应用