网站缓存本质上是在用户端或中间节点保存一份响应副本，目的是减少重复请求、提升加载速度。但缓存机制一旦配置不当，就会把本应隔离的会话数据、账户信息、交易记录甚至后台接口响应原样存进浏览器、CDN节点或代理服务器。攻击者不需要入侵服务器，只需要翻看缓存副本或利用共享缓存的时间差，就能拿到他人的敏感数据。这类问题在真实业务中非常普遍，尤其是登录后的个人信息接口、订单详情页、带权限控制的后台Ajax接口，以及手机号、邮箱、身份证号等字段一旦被缓存，泄露风险就变成持续性的数据暴露。
要解决缓存泄露敏感数据的问题，必须先明确一个核心原则：任何包含用户私有信息或需要登录后才能访问的响应，都不应该被共享缓存存储。共享缓存包括CDN、反向代理、企业出口代理等所有位于用户与源站之间的公共存储节点。私有缓存（浏览器本地缓存）虽然只属于单个用户，但在共用电脑、浏览器账号同步、恶意扩展读取等场景下同样可能造成泄露，因此也需要严格限制。
先区分响应类型，再决定缓存策略很多开发团队习惯在全局配置里统一设置缓存头，比如给所有静态资源设置一年过期时间，给所有HTML页面设置no-cache。这种一刀切的做法恰恰是缓存泄露的根源。正确的做法是按响应内容类型和用户状态划分缓存策略。未登录用户看到的公开页面可以缓存，登录后返回的个性化内容必须禁止共享缓存，并尽量缩短私有缓存时间。对于REST API接口，凡是返回个人数据、账户余额、地址列表、订单记录、聊天内容的响应，都应该明确返回Cache-Control: private, no-store或者至少是no-cache配合must-revalidate。no-store是最彻底的指令，它告诉所有缓存节点不要存储任何副本；private则只允许浏览器私有缓存，不允许CDN等共享缓存存储。
实际场景中，一个典型的错误是登录接口返回了Set-Cookie，但响应头里没有设置Cache-Control: no-store。部分代理服务器会把带有Set-Cookie的响应缓存下来，导致下一个用户请求同一个URL时直接拿到上一个用户的登录凭证。类似问题也出现在找回密码、绑定手机号、修改邮箱等操作后的响应中。只要响应内容与用户身份相关，就必须显式声明禁止缓存，不能依赖浏览器或中间节点的默认行为。
用响应头组合堵住缓存泄露通道最稳妥的防护方式是同时设置多个响应头，形成组合限制。对于敏感数据接口，建议返回以下头部：
Cache-Control: no-store, no-cache, must-revalidate, private Pragma: no-cache Expires: 0 Vary: Cookie, Authorization
其中no-store保证任何缓存节点都不保存响应副本；no-cache和must-revalidate要求每次使用缓存前必须向源站验证；private禁止共享缓存存储；Pragma和Expires用于兼容旧版HTTP/1.0客户端；Vary: Cookie, Authorization则告诉缓存节点，当请求携带不同的Cookie或Authorization头时，响应内容不同，必须分开存储。这个Vary头非常关键，很多CDN默认只根据URL和Host做缓存键，如果响应头没有Vary，同一个URL在不同登录用户之间返回的内容会被当成同一份缓存，直接造成跨用户数据串号。
对于确实需要缓存的静态资源，也要避免把用户标识拼进URL。比如有些网站会把用户ID或手机号作为图片、PDF、Excel导出文件的查询参数，如/download?idcard=xxx&user=123。这类URL一旦被CDN缓存，等于把用户标识和文件内容绑定存储。正确做法是使用不可预测的随机token作为资源标识，并且对下载接口单独设置no-store，或者在CDN层配置规则，对包含特定参数的请求绕过缓存。
CDN与反向代理层的缓存规则要细化到路径源站返回正确的缓存头只是第一道防线，CDN和反向代理往往有自己的缓存配置，可能会覆盖源站指令。很多CDN默认会缓存所有GET请求的响应，即使源站返回了no-store，如果CDN配置了强制缓存策略，仍然会把敏感数据存下来。因此必须在CDN控制台或反向代理配置中，针对敏感路径设置明确的缓存规则。例如，所有/api/user/、/account/、/order/、/admin/开头的路径，强制设置为不缓存；所有包含Cookie或Authorization请求头的请求，强制绕过缓存；对于返回Set-Cookie的响应，强制不缓存。
在Nginx反向代理场景中，可以通过配置来强制覆盖上游的缓存行为。下面是一段示例配置，针对敏感接口路径关闭缓存：
location ~ ^/(api/user|account|order|admin)/ {
proxy_cache off;
proxy_no_cache 1;
proxy_cache_bypass 1;
add_header Cache-Control "no-store, no-cache, must-revalidate, private";
add_header Pragma "no-cache";
add_header Expires 0;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://backend;
}
这段配置通过proxy_cache off直接关闭该路径的代理缓存，proxy_no_cache和proxy_cache_bypass确保即使有缓存也不会使用，同时由Nginx统一追加禁止缓存的响应头，防止上游应用遗漏。对于使用其他反向代理或CDN的场景，思路一致：在边缘节点强制拦截敏感路径，不让缓存策略完全依赖应用层。
浏览器本地缓存同样需要精细控制很多人只关注CDN和代理缓存，忽略了浏览器本地缓存带来的泄露风险。浏览器缓存存储在用户设备上，如果用户使用公共电脑或共享设备，退出登录后，之前缓存的个人信息页面仍然可以通过后退按钮、历史记录或缓存文件被下一个人看到。即使是在个人设备上，恶意浏览器扩展、跨站脚本攻击也可能读取缓存内容。因此，对于包含个人信息的HTML页面和接口响应，应该使用Cache-Control: no-store，而不是仅仅使用no-cache。no-cache虽然要求重新验证，但浏览器仍然可能存储响应副本，而no-store则明确不存储。
另外，浏览器历史记录和BFCache（往返缓存）也会保留页面状态。即使用户点击退出，如果页面在BFCache中，点击后退仍可能看到退出前的完整页面内容。可以通过在敏感页面加入以下meta标签和脚本，进一步降低BFCache带来的泄露风险：
这段代码在页面从BFCache恢复时强制刷新，刷新后由于用户已退出登录，服务端会返回登录页或公开内容，避免旧页面残留。对于单页应用，还需要在路由切换和退出登录时主动清理内存中的用户数据，并调用接口让服务端使会话失效。
针对敏感接口的额外防护措施除了缓存头，还可以从接口设计层面减少缓存泄露的可能性。敏感数据接口应尽量使用POST请求而不是GET请求。虽然HTTP规范并没有禁止缓存POST响应，但主流缓存节点和浏览器对POST响应的缓存处理比GET更谨慎，很多CDN默认不缓存POST响应。把查询个人信息的接口从GET改为POST，可以显著降低被共享缓存存储的概率。不过要注意，POST请求本身也可能被某些代理缓存，所以仍然需要配合no-store响应头。
另一个有效手段是在敏感接口的URL中加入随机参数或时间戳，使每个请求的URL都不同，从而避免命中共享缓存。例如，前端在请求订单详情时，可以在URL后追加一个随机数或当前时间戳：/api/order/detail?id=123&_t=1716000000000。这样即使CDN错误地缓存了响应，由于URL不同，下一个用户也不会命中同一份缓存。但这种方法只能作为辅助手段，不能替代正确的缓存头设置，因为随机参数会增加缓存碎片，且无法防止浏览器本地缓存。
对于下载类接口，比如导出用户数据、下载账单、下载身份证照片等，必须单独设置no-store，并且建议使用一次性下载token。服务端生成一个短时效的随机token，前端通过该token下载文件，下载完成后token立即失效。这样即使URL被缓存或泄露，攻击者也无法在token过期后获取文件内容。同时，下载接口的响应头应明确禁止缓存，文件流本身也不要设置过长的过期时间。
日志与监控中发现缓存泄露的迹象缓存泄露往往不会直接报错，而是表现为用户数据串号、登录状态异常、页面显示他人信息等。要主动发现这类问题，需要在日志和监控中增加相应的检测点。可以在应用层记录每个请求的响应头，检查敏感接口是否返回了正确的Cache-Control。也可以在CDN日志中分析缓存命中率，如果某个敏感接口的缓存命中率异常升高，说明该接口可能被错误缓存。还可以在用户反馈渠道中设置专门的数据泄露举报入口，一旦收到串号报告，立即排查缓存配置。
更主动的做法是在测试环境中模拟不同用户请求同一个URL，检查响应内容是否一致。如果两个不同账号请求同一个接口返回了相同内容，且响应头中允许缓存，就说明存在共享缓存泄露风险。这种测试可以集成到自动化测试流程中，每次上线前对敏感接口做一轮缓存策略验证。
缓存策略需要贯穿开发、测试、上线全流程缓存安全不是上线前检查一次就能一劳永逸的。新功能开发时，开发人员可能忘记为新增接口设置缓存头；测试环境可能没有配置CDN，导致缓存问题在上线后才暴露；CDN配置变更也可能意外覆盖源站指令。因此，需要把缓存策略纳入代码规范和部署流程。可以在代码审查清单中加入缓存头检查项，要求所有涉及用户数据的接口必须显式声明Cache-Control。在CI/CD流水线中增加自动化检查，扫描代码中新增的API路由，验证响应头是否包含no-store或private。对于CDN配置，建议使用版本管理和变更审批，每次修改缓存规则都记录原因和影响范围。
另外，安全团队应该定期对线上环境做缓存策略审计，重点检查登录后页面、个人信息接口、订单接口、后台管理接口的响应头。审计工具可以模拟带Cookie和不带Cookie的请求，对比响应头差异，找出那些在不同用户状态下返回相同缓存策略的接口。对于发现的缓存泄露风险，按照漏洞管理流程进行修复和验证。
缓存安全防护的核心不是禁用缓存，而是精准控制缓存边界。公开内容可以大胆缓存，敏感内容必须彻底禁止缓存。通过响应头组合、CDN规则、接口设计、浏览器端控制以及全流程审计，可以把缓存泄露的风险降到最低。任何涉及用户私有数据的响应，都应该默认不缓存，只有在明确确认内容公开且无用户关联时，才允许缓存。这个原则落实到位，缓存泄露敏感数据的问题就能得到有效控制。
