安全基线检查聚焦Brotli在Nginx中的启用方式是否符合最小风险原则：验证是否扩大侧信道攻击面、内存与进程是否稳定、兼容性策略是否规避降级漏洞、构建与运行时环境是否可信。
安全基线检查不直接评估 Brotli 算法本身是否“安全”，而是验证它在 Nginx 中的启用方式是否符合最小风险原则——重点看是否引入额外攻击面、是否放大资源滥用风险、是否与现有安全机制冲突。
检查 Brotli 是否扩大侧信道攻击面
Brotli 本身不涉及头部压缩，不会像 HTTP/2 的 HPACK 那样引发 CRIME/BREACH 类侧信道风险。但需确认它未与高风险机制共存：
- 若同时开启 http2 且未强制 TLS 1.3，应检查是否已禁用不安全协议（
ssl_protocols TLSv1.2 TLSv1.3;），避免 Brotli 压缩内容被嵌套在脆弱的加密通道中放大泄露可能 - 确保响应头中不回显用户输入（如
X-Debug、X-Forwarded-For）到可被 Brotli 压缩的字段，防止其进入压缩上下文参与模式匹配 - 不将 Brotli 用于含敏感动态数据的 API 响应（如含 token、session ID 的 JSON），这类内容更适合由后端控制输出，而非交由 Nginx 动态压缩
验证内存与进程稳定性是否满足基线要求
等保三级和金融行业基线普遍要求“服务进程无非预期崩溃、内存占用可控”。Brotli 若配置不当会触发 worker 进程 OOM 被系统 kill（signal 9），这属于明确的基线不合规项：
- 检查
brotli_comp_level是否 ≤ 6：级别 11 在生产环境极易导致单次压缩分配超 10MB 内存，违反“单请求资源消耗应有合理上限”原则 - 确认
brotli_min_length≥ 1000：避免对空响应、小 JSON（如{"ok":true}）反复触发压缩流程，造成事件循环阻塞，影响服务可用性 - 核对
brotli_types是否排除高风险类型：如不包含application/octet-stream或未校验的上传回调响应，防止恶意构造的大二进制体触发内存暴涨
确认兼容性策略是否规避降级漏洞
安全基线要求“不因兼容性设计引入逻辑绕过”。Brotli + gzip 双压缩不是并行启用，而是基于 Accept-Encoding 的协商回落。需检查：
- 是否关闭了全局
gzip on，仅保留窄范围兜底（如仅gzip_types text/plain;），防止同一响应被重复判断、重复缓冲 - 是否在
brotli_types和gzip_types中无重叠 MIME 类型，避免 Nginx 内部 filter 链异常或 header 冲突 - 是否通过
add_header Vary "Accept-Encoding"显式声明协商维度，确保 CDN 和代理能正确缓存不同编码版本，防止缓存污染导致未压缩内容误发给旧客户端
审查构建与运行时环境是否可信
基线要求“所有模块来源可追溯、编译环境受控”。Brotli 是第三方动态模块，非 Nginx 官方内置：
- 运行
nginx -V，确认 configure 参数中--add-module指向的是经内部审计的源码路径，而非公网随意下载的预编译包 - 检查模块加载顺序：Brotli filter 必须在
ngx_http_gzip_filter_module之后、ngx_http_chunked_filter_module之前，否则可能引发缓冲区拷贝异常，已被多个 CVE 关联（如 CVE-2023-44487 衍生场景） - 禁止启用
--with-debug编译参数上线，该选项会在 error.log 中高频打印内存分配痕迹，既暴露内部结构，又可能因日志刷盘拖慢响应
