浏览器缓存本身非等保三级强制审计项,但配置不当会间接违反数据完整性、安全审计和访问控制要求;Nginx通过精准设置Cache-Control等响应头,既提升性能又支撑合规:静态资源用immutable+max-age=31536000并配expires 1y,HTML设no-cache/must-revalidate,API接口默认no-store。

浏览器缓存本身不直接属于等保三级的强制审计项,但若配置不当,可能间接违反“数据完整性”“安全审计”和“访问控制”要求——比如缓存敏感 HTML 或 API 响应导致越权信息残留、未校验的旧页面绕过新权限逻辑、或缓存日志中暴露脱敏失败的参数。Nginx 通过精准控制 Cache-Control 等响应头,既能提升性能,又能支撑等保合规落地。
静态资源:用 immutable + 长期 max-age,确保内容不变性
带哈希或版本号的 JS/CSS/图片/字体(如 app.f3a8b2.js、logo.e9d1c4.png)内容实质固定,适合长期强缓存:
- 在 location 块中匹配扩展名:
location ~* \.(js|css|png|jpg|gif|woff2|svg)$ - 设置响应头:
add_header Cache-Control "public, immutable, max-age=31536000"; - 同时配
expires 1y;补全Expires头(兼容老旧客户端) -
关键前提:文件名必须含构建时生成的唯一哈希——否则
immutable会锁死错误版本,造成更新不可见
HTML 页面:禁用强缓存,强制每次校验
入口 HTML 通常动态生成,含权限判断、菜单状态等实时逻辑,浏览器不能跳过服务器直接复用本地副本:
在 Linux 上通过 Chrome 挂载/VNC 自动发布小红书长笔记。Agent 撰写标题和正文后执行 xhs_publish.sh --publish --submit,触发小红书发布。
- 匹配根路径或 HTML 文件:
location = / { ... }或location ~* \.html$ - 设
add_header Cache-Control "no-cache, must-revalidate";或"private, max-age=0" - 避免使用
max-age=300等短时效值——仍可能跳过服务端权限校验,导致用户看到过期结构或越权按钮 - 配合 ETag 或
Last-Modified(Nginx 默认开启),使校验请求返回 304,节省带宽又不失安全性
API 与 JSON 接口:默认 no-store,防敏感数据滞留
JSON 接口常返回用户数据、令牌、权限列表等高敏内容,浏览器不得缓存:
- 对
/api/、/v1/或*.json路径,显式关闭:add_header Cache-Control "no-store"; -
no-store比no-cache更严格:禁止写入磁盘、内存甚至 DevTools 的 Application → Cache Storage - 若个别接口允许弱缓存(如天气预报每10分钟更新),可设
max-age=600, stale-while-revalidate=30,但需确认后端未自带冲突的Cache-Control(Nginx 的add_header是追加,非覆盖)
缓存策略验证与等保衔接点
配完不验证,等于没配;而验证方式直接影响等保日志审计有效性:
- 重启后用
curl -I https://yoursite.com/app.js或浏览器开发者工具 Network 标签页,检查响应头是否含预期Cache-Control和Expires - 特别关注 HTML 和登录页响应头:必须不含
public或长max-age,否则测评时会被判定为“未控制前端缓存风险” - 若启用了
proxy_cache,检查X-Cache-Status和Age头,确保 HTML 不被 Nginx 自身缓存——等保要求“所有用户请求必须经服务端鉴权”,Nginx 缓存 HTML 会绕过后端权限逻辑 - 日志中记录的
$request_uri和$http_cache_control(需自定义 log_format)可用于回溯异常缓存行为,满足“安全事件可审计”要求

















