浏览器缓存本身不直接导致缓存投毒，但它是整个缓存链路的起点，常被攻击者用作诱导用户触发污染请求的“跳板”；需检查敏感接口是否误设public/max-age、遗漏no-store、缓存键是否含不可信变量、Service Worker等扩展机制是否绕过控制，以及CSP/Referrer策略是否与缓存冲突。

浏览器缓存本身不直接导致缓存投毒，但它是整个缓存链路的起点，且常被攻击者用作“跳板”——比如诱导用户点击恶意链接，触发带污染头的请求，再经由CDN或反向代理完成投毒。安全基线检查中，不能只盯着Nginx的proxy_cache，必须把浏览器缓存策略纳入上下文验证。

确认关键响应头是否被错误地允许缓存

浏览器是否缓存某个响应，取决于后端返回的Cache-Control、Expires、ETag等头。若敏感接口（如登录页、用户中心）返回了public、max-age=3600或未设no-store/no-cache，就可能被浏览器缓存，进而被用于构造投毒链：

• 用curl或浏览器开发者工具检查典型敏感路径（/login、/api/user/profile）的响应头，确认是否存在Cache-Control: public或max-age大于0
• 重点排查是否遗漏了no-store：它禁止浏览器和中间代理缓存任何内容，比no-cache更严格，适用于含令牌、密码字段的响应
• 若业务强制要求某些页面可缓存（如静态资源），确保其URL路径与动态接口完全隔离，避免通过路径拼接绕过限制

检查是否误将用户输入反射进缓存键或响应体

浏览器缓存虽是客户端行为，但它的key（URL+部分请求头）会影响上层缓存是否复用该响应。如果Nginx配置了基于$http_user_agent或$http_accept_language的proxy_cache_key，而这些头又被前端JS读取并拼接到请求中，就可能形成“可控缓存键”：

小红书长文-谷歌浏览器

在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit，触发小红书发布。

下载

• 搜索Nginx配置中所有proxy_cache_key指令，确认是否包含不可信变量（如$http_x_forwarded_for、$arg_ref、$http_ua）
• 对使用了Vary头的接口（如Vary: User-Agent），检查是否在HTML或JS中动态修改了User-Agent字符串——这会让不同UA的用户拿到彼此的缓存副本
• 用不同User-Agent发起相同URL请求，对比响应是否一致；若不一致，说明Vary生效，需确认该差异是否由服务端可控逻辑引入

验证是否禁用了危险的缓存扩展机制

某些前端框架或CDN会启用Service Worker、HTTP/2 Server Push、Prefetch Link等机制，它们可能绕过常规缓存控制逻辑，成为投毒入口：

• 检查HTML源码中是否存在<link rel="prefetch">或<link rel="preload">指向动态API，尤其是带参数的URL
• 访问站点后，在浏览器Application → Service Workers面板中查看是否注册了自定义worker；若有，审查其fetch事件监听逻辑是否无条件缓存POST响应或含Set-Cookie的响应
• 禁用HTTP/2 Server Push：在Nginx中移除http2_push和http2_push_preload指令，避免服务端主动推送可能被污染的内容

排查浏览器缓存与CSP/Referrer策略的冲突

缓存投毒常配合XSS或开放重定向利用。若浏览器缓存了含不安全内联脚本的页面，而CSP又未严格限制script-src，则污染效果会被放大：

• 检查响应头中Content-Security-Policy是否包含'unsafe-inline'或宽泛的*.example.com，尤其在被缓存的HTML页面中
• 验证Referrer-Policy是否为no-referrer-when-downgrade以上级别，防止缓存页面跳转时泄露敏感URL参数
• 对使用localStorage/sessionStorage存储token的前端，确认其加载的JS文件本身未被缓存投毒——即检查JS响应是否含Cache-Control: no-store