菜单
HTTP 安全响应头白盒审计——对照基线检查 HSTS / X-Frame-Options / X-Content-Type-Options / Referrer-Policy / Permissions-Policy / COOP / COEP / CORP / CORS / CSP 声明存在性是否齐全、 值是否符合最小权限基线、是否覆盖所有响应路径（含 4xx / 5xx）。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
白盒建模——一次深度建模产出五张共享模型：项目架构（技术栈/分层/框架自有封装/闭源依赖位置）、 入口点（路由/中间件信任边界）、认证与权限（会话/角色/多租户/归属字段）、业务（实体/流程状态机/ 业务不变量/高价值资产）、全局威胁（攻击面×漏洞类别的适用性映射，供下游逐一全测）。本能力不做漏洞判定，为后续 漏洞维度分析建立共享底图。
OS 命令注入综合检测——覆盖直接命令拼接 / shell 元字符 / 参数注入 / 间接 RCE，按回显 / 时间 / 带外通道分诊。 流量中参数值含主机名 / URL / 文件名 / 命令片段、响应里出现 shell 错误关键字（`/bin/sh` / `cmd.exe` / `command not found`）、注入 `sleep N` 耗时增加、上传后异步处理链路时使用。
文件上传多策略综合检测——覆盖扩展名 / MIME / 魔术数 / 解析漏洞 / 上传链组合（LFI / Zip Slip / SVG XSS / SVG XXE）。 流量含 multipart/form-data 上传、响应回显落盘路径、上传后文件可被 GET 解析、上传字段含 filename / path 可控时使用。
IDOR 水平越权检测 — 通过替换资源标识符（ID/UUID/路径）访问他人资源的风险；适用于用户资料、订单、文档、租户隔离场景。
检测路径穿越和本地文件包含（LFI）风险；当目标存在文件读取/下载/预览功能且含路径参数时触发；适用于文件下载、日志查看、模板加载等场景。
黑盒建模 — 迭代式攻击面建模，按站点级 / 页面级 / 功能级三粒度推进；进入新页面即触发一次页面级建模、切换新身份各刷新一次，产出端点账本与页面语义模型，为后续漏洞维度的适用性判断提供依据。
| name | security-header-audit |
| description | HTTP 安全响应头白盒审计——对照基线检查 HSTS / X-Frame-Options / X-Content-Type-Options / Referrer-Policy / Permissions-Policy / COOP / COEP / CORP / CORS / CSP 声明存在性是否齐全、 值是否符合最小权限基线、是否覆盖所有响应路径（含 4xx / 5xx）。 |
| when-to-use | 当项目为 Web 应用且存在 HTTP 响应头设置或 Cookie 安全属性设置时 |
| allowed-tools | bash,read_file,list_files,rg,list_skills |
| user-invocable | true |
按 代码 pattern + 配置文件 + 中间件依赖 分类（不按业务命名）。
代码 pattern 维度（grep 命中模式）：
response.setHeader( / res.setHeader( / ctx.set( / resp.Header().Set(.headers(). / HttpHeaders.add( / HttpServletResponse.setHeader(app.use(helmet( / helmet.contentSecurityPolicy( / helmet.hsts(SECURE_HSTS_SECONDS / SECURE_BROWSER_XSS_FILTER / SECURE_CONTENT_TYPE_NOSNIFF / SECURE_PROXY_SSL_HEADERapp/Http/Middleware/ 自定义 header 中间件 / header() helperconfig.action_dispatch.default_headers / config.force_sslResponse.Headers.Add( / app.UseHsts()配置文件 / 服务器维度：
nginx.conf / *.conf 含 add_header.htaccess / httpd.conf 含 Header set / Header always setCaddyfile 含 header blockhttp-response set-headergatewayResponses / Kong response-transformer / Traefik middleware依赖 / 中间件维度：
package.json 含 helmet / koa-helmet / fastify-helmetpom.xml 含 spring-security / spring-boot-starter-securityrequirements.txt 含 django-csp / secure / django-securitygo.mod 含 unrolled/secure / 自定义 header middlewarecomposer.json 含 bepsvpt/secure-headers反向信号（不命中本能力）：
unsafe-inline / source-list 收敛）→ 转 csp-audit；本能力只判 CSP 声明存在性 + 与其他 header 联动Secure / HttpOnly / SameSite → 转 session-security 等 cookie 维度 skillAccess-Control-Allow-* 是否声明 + 联动其他 headersource 是 HTTP 响应构造代码——中间件链 / 拦截器栈 / 框架 header 配置 / 静态资源服务器配置 / CDN 边缘规则。sink 是 HTTP 响应输出到浏览器。
任何防御性安全 header 缺失或值弱化，浏览器就无法兜底拦截对应的客户端攻击——每个 header 各防御一类具体攻击面：
frame-ancestors 缺失 → 页面被恶意站点 iframe 嵌入（点击劫持）.txt 当 HTML/JS 执行Access-Control-Allow-Credentials 组合时尤其危险）1; mode=block 在旧浏览器会引入反射 XSS 通道本能力是静态值审计——不依赖动态触发即可对照基线判断 header 是否声明、值是否符合最小权限。
代码层 source 集合（按"谁可能写响应 header"分类）：
HeadersConfigurer / helmet 各子模块 / Django SecurityMiddleware / Laravel middleware / Rails default_headersOncePerRequestFilter / Express app.use((req,res,next)=>{...}) / Gin gin.HandlerFunc 写 header / Koa ctx.set(...)settings.SECURE_* / Rails config.force_ssl / Spring Boot server.servlet.session.cookie.*add_header / Apache Header set / Caddy header block代码层 sink 集合（响应输出位置）：
return Response(...) / res.send(...) / res.json(...) / c.JSON(...)@ExceptionHandler / Express app.use(errorHandler) / try/catch 内的错误 JSON 输出——容易绕过 header 中间件数据流追踪规则：
always 标志 / CDN 边缘规则）或弱化（前层设了 max-age=31536000，后层覆盖成 max-age=0）if (env == "dev") 是否会动态关闭 header闭源依赖 / 边缘节点不可见时落 static-unknown（参 §11）。
按"安全 header 维度 × 缺失 vs 弱化"组织：
| Header | 缺失场景 | 危险配置场景 |
|---|---|---|
| Strict-Transport-Security (HSTS) | 未声明；仅声明在 HTTPS 端点但未声明在跳转 endpoint | max-age=0（实际禁用）；缺 includeSubDomains；缺 preload 但已提交 preload list |
X-Frame-Options / CSP frame-ancestors | 未声明任何 frame 保护 | ALLOWALL（非标准值）；ALLOW-FROM 已废弃但仍用；frame-ancestors * |
| X-Content-Type-Options | 未声明 | 声明非 nosniff 值 |
| Referrer-Policy | 未声明 | unsafe-url / no-referrer-when-downgrade（默认值，可能泄露 query） |
| Permissions-Policy / Feature-Policy | 未声明 | 未限制摄像头 / 麦克风 / geolocation / payment 等敏感能力 |
| Cross-Origin-Opener-Policy (COOP) | 未声明 | 缺 same-origin，允许跨源 window.opener 持有引用 |
| Cross-Origin-Embedder-Policy (COEP) | 未声明 | 跨源资源加载未受限，无法启用跨源隔离环境 |
| Cross-Origin-Resource-Policy (CORP) | 未声明 | 资源可被任意 origin embed（CORS 旁路） |
| Access-Control-Allow-Origin (CORS) | 业务确需 CORS 但未声明（功能性问题） | 反射 Origin + Access-Control-Allow-Credentials: true（详见 dangerous-config） |
| Content-Security-Policy (CSP) | 未声明（本能力只判存在性） | 详细 directive 缺陷 → csp-audit |
| X-XSS-Protection | n/a（已废弃，不声明是正确做法） | 错误开启 1; mode=block（在旧 Chrome 引入反射 XSS） |
联动场景：
按项目结构定位"哪里在设 response header"。
下列框架 / 项目类型仅作类似项目示例 不限于此；以目标实际栈为准。
WebSecurityConfigurerAdapter.configure(HttpSecurity).headers().*；新版 SecurityFilterChain bean → .headers(headers -> ...)@Component implements HandlerInterceptor / OncePerRequestFilterapplication.yml 含 server.servlet.headers.*@ControllerAdvice + @ExceptionHandler 是否同样走 header filtersettings.py：MIDDLEWARE 含 SecurityMiddleware；SECURE_HSTS_SECONDS / SECURE_HSTS_INCLUDE_SUBDOMAINS / SECURE_HSTS_PRELOAD / SECURE_CONTENT_TYPE_NOSNIFF / SECURE_REFERRER_POLICY / SECURE_CROSS_ORIGIN_OPENER_POLICYdjango-csp（如装）：CSP_* settingsresponse["X-Frame-Options"] = ...app.use(helmet()) 整体启用（默认开多项）；或细粒度 app.use(helmet.hsts({...}))app.use((err,req,res,next)=>{...}) 是否在 helmet 之前注册（顺序错则错误响应漏 header）unrolled/secure middleware：secure.New(secure.Options{...})gin.HandlerFunc：c.Header(...) / c.Writer.Header().Set(...)app/Http/Middleware/ 自定义 SecurityHeaders；bepsvpt/secure-headers 包配置config.action_dispatch.default_headers / config.force_ssl；secure_headers gem config/initializers/secure_headers.rbadd_header Strict-Transport-Security "..." always;（缺 always 标志只在 200 响应生效——4xx / 5xx 漏）；map block 内的 header 设置Header set / Header always set（同 Nginx always 语义）header { ... } block；header_up / header_down for reverse proxygatewayResponses 对默认错误响应单独配；Kong response-transformer plugin| 框架 | 安全形态 | 危险形态 |
|---|---|---|
| Spring Security（旧式） | .headers().frameOptions().sameOrigin().and().contentTypeOptions().and().httpStrictTransportSecurity().maxAgeInSeconds(31536000).includeSubDomains(true) | 默认 .headers() 未配置具体子项；显式 .headers().disable() |
| Spring Security（Lambda DSL） | .headers(h -> h.frameOptions(f -> f.deny()).contentSecurityPolicy(c -> c.policyDirectives("..."))) | 漏调用 headers(...) 整段 |
| Express + helmet（默认） | app.use(helmet()) 一次开多个 | app.use(helmet({contentSecurityPolicy: false, hsts: false})) 显式关 |
| Express + helmet（细粒度） | app.use(helmet.hsts({maxAge: 31536000, includeSubDomains: true, preload: true})) | 只 app.use(helmet.contentSecurityPolicy()) 单项，其他默认全开但实际未启用 helmet 完整套件 |
| Django settings（强） | SECURE_HSTS_SECONDS = 31536000 + SECURE_HSTS_INCLUDE_SUBDOMAINS = True + SECURE_HSTS_PRELOAD = True + SECURE_CONTENT_TYPE_NOSNIFF = True + SECURE_REFERRER_POLICY = 'strict-origin-when-cross-origin' | SECURE_HSTS_SECONDS = 0 / SECURE_PROXY_SSL_HEADER 误配置导致 Django 误判 HTTPS |
| Django middleware 顺序 | SecurityMiddleware 在 MIDDLEWARE 列表靠前 | SecurityMiddleware 缺失或被自定义错误处理 middleware 截断 |
| Nginx | add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always; | 缺 always（仅 200 生效，4xx / 5xx 漏）；定义在 server 上层但子 location 重新 add_header 后外层 add_header 全失效（Nginx add_header 不继承） |
| Apache | Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" | Header set 不带 always（同上） |
| Caddy | header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" | 配置在错误 site block；reverse proxy 未传递 header |
| Cloudflare Workers | viewer-response 阶段统一加 header | 仅对部分路径添加；origin 已设但 worker 覆盖弱化 |
| AWS API Gateway | gatewayResponses 显式给所有默认错误响应加 header | 仅配置成功路径，DEFAULT_4XX / DEFAULT_5XX 漏 header |
| Go + unrolled/secure | secure.New(secure.Options{STSSeconds: 31536000, STSIncludeSubdomains: true, ContentTypeNosniff: true, FrameDeny: true, ...}) | IsDevelopment: true（dev 模式跳过全部 header）误开到生产；中间件注册顺序在 recovery 之后 |
| Rails | config.force_ssl = true + secure_headers gem 完整配置 | force_ssl = false；default_headers 自定义但漏 HSTS |
Nginx add_header 不继承陷阱（高发 FN）：
server { add_header X-Frame-Options DENY; } + 内层 location /api { add_header Cache-Control no-store; } → API 路径丢失 X-Frame-Options。修复：每个 location 重复加，或用 include 文件统一。helmet 默认配置陷阱：
Cross-Origin-Opener-Policy: same-origin，可能影响 OAuth 跨源 window 流程——业务侧若关 COOP 需评估X-XSS-Protection: 0（关闭已废弃 header），符合 OWASP 建议；老项目若手动开成 1; mode=block 反而引入反射 XSS加载本 skill 时按这些问题思考（按 sink 语义而非业务命名）：
max-age 是否足够长（≥ 6 个月）+ includeSubDomains？XFO 是 DENY / SAMEORIGIN 而非自定义 ALLOW-FROM？Referrer-Policy 比 no-referrer-when-downgrade 严格？/static/*.js 直出可能漏project-framework-analysis 输出的项目结构 / 中间件链 / 反向代理配置helmet / secure_headers / unrolled/secure / django-csp 等专门库# 应用层 header 写入
rg "setHeader\(|Header\(\)\.Set\(|res\.set\(|ctx\.set\(|response\.headers" --type-add 'web:*.{java,go,py,js,ts,php,rb}'
# Spring Security headers config
rg "\.headers\(\)|HeadersConfigurer|httpStrictTransportSecurity|frameOptions|contentTypeOptions"
# Django SECURE_* 设置
rg "SECURE_HSTS_|SECURE_CONTENT_TYPE_NOSNIFF|SECURE_REFERRER_POLICY|SECURE_BROWSER_XSS|SECURE_PROXY_SSL_HEADER" --type py
# helmet
rg "helmet\(|helmet\." --type js --type ts
# Nginx / Apache / Caddy
rg "add_header|Header (always )?set|^\s*header\s+\w+-\w+" --type-add 'cfg:*.{conf,vcl}' -g 'Caddyfile'
# CDN / edge
rg "Response Headers Policy|gatewayResponses|response-transformer" --type yaml --type json
按 §4 表格逐 header 走：
server / location block 是否覆盖动态路由与静态资源add_header 继承陷阱：是否每个 location 都重复设@ControllerAdvice / @ExceptionHandler 是否走同一 header filterapp.use(errorHandler) 是否在 helmet 之后注册gatewayResponses 是否覆盖 DEFAULT_4XX / DEFAULT_5XX调用 dataflow-analysis 跨函数追"哪些 handler 走了哪条 middleware 链"；调用 sast-scan 找未覆盖的 header 设置位置。
以下是已知的检查角度，作为基线起点而非必检硬清单。结合目标代码动态调整，按三态标注（
[x]/[-]/[+]）处置。
关键安全 header 存在性 + 值基线（详细攻击场景参见 missing-critical-headers.md）：
Strict-Transport-Security 已声明，max-age ≥ 15552000（6 个月）且含 includeSubDomainsX-Content-Type-Options: nosniff 已声明X-Frame-Options: DENY 或 SAMEORIGIN（或 CSP frame-ancestors 已覆盖）Content-Security-Policy 已声明（细节走 csp-audit）Referrer-Policy 已声明且严于 no-referrer-when-downgrade（建议 strict-origin-when-cross-origin）Permissions-Policy 已声明，限制摄像头 / 麦克风 / geolocation / payment 等敏感能力Cross-Origin-Opener-Policy: same-origin 已声明（除非业务需要跨源 window）Cross-Origin-Embedder-Policy 已声明（如需启用跨源隔离）Cross-Origin-Resource-Policy 已声明（建议 same-origin 或 same-site）X-XSS-Protection 未声明或为 0（已废弃，开启反引入反射 XSS）CORS header 存在性 + 联动（CORS 配置风险细节参见 cors-misconfiguration.md；过宽配置归 dangerous-config）：
Access-Control-Allow-Origin 不为 *（或不与 Allow-Credentials: true 组合）覆盖完整性：
add_header 继承陷阱已检查（每个 location 单独验证）闭环判定（confirmed / suspected / not_vulnerable）以 common/closure-verification.md 为准。本能力作为白盒原子能力，判定上限为
static-confirmed，不等于动态 confirmed。为什么这里是「必须」：本节属交付契约——产物结构关系到下游
result-with-file与 coverage-ledger 的机器消费，按 header 维度聚合或区间表达会让单条 header 缺陷无法回溯到具体响应路径。
static-confirmed（白盒上限，落 status=needs_review）：
max-age=0 / 缺 includeSubDomains）static-unknown（落 status=needs_review + 标注 unknown）：
not_vulnerable（落 status=not_vulnerable）：
[-] n/a (原因)）升级路径（白盒不能独立判 confirmed）：
confirmed禁止白盒独立判 confirmed——配置层证据不等于浏览器实际收到的 header（CDN 边缘可能覆盖）。
每确认一条候选立即 append 一行到 shared/coverage-ledger/findings/security-header-audit.jsonl：
{
"id": "secheader-001",
"title": "HSTS 缺失 includeSubDomains",
"severity": "medium",
"cwe": "CWE-693",
"endpoint_pattern": "/*",
"header_name": "Strict-Transport-Security",
"value": "max-age=31536000",
"deficiency_type": "weak-value-missing-includeSubDomains",
"status": "needs_review",
"confidence": "static-confirmed",
"file_location": "config/nginx.conf:42",
"source_report": "security-header-audit",
"description": "..."
}
字段约束：
(endpoint_pattern, header_name, value, deficiency_type) 四元组任一不同即各自独立成行——禁止按 header 聚合或按端点折叠endpoint_pattern 填该响应路径模式（如 /api/* / /static/* / /error/4xx）；全站统一配置填 /*header_name 填具体 header（如 Strict-Transport-Security / X-Frame-Options）value 填当前实际声明值；未声明填 null 或 <missing>deficiency_type ∈ missing | weak-value-* | wrong-value-* | inconsistent-coverage，名称带 header 语义后缀file_location 填 file:line，多层叠加时填实际生效那一层禁止：
why：header 审计的"已防护"结论是覆盖完整性产物声明，缺失反向验证会让下游误信"该子系统 header 已合规"。
写"所有安全 header 已合规"前，产物必须包含：
static-unknown 单元格（动态决策 / 闭源边缘）的具体原因清单不完整 → 结论降级 partial-coverage。
反例 1：应用层未设但前置 CDN/反向代理统一注入
.headers()pom.xml 无 security 相关依赖但生产实测响应有完整 headerstatic-unknown 推 graybox 端实测，确认后归 not_vulnerable反例 2：helmet 配置项已设但项目接 Nginx，Nginx 同步设置
反例 3：DEV 环境关 HSTS
if (env === 'production') app.use(helmet.hsts({...}))；dev 不开反例 4：helmet 老版本默认 X-XSS-Protection: 1; mode=block
helmet.xssFilter(false)package.json helmet 版本 < 5.0；未显式关闭 xssFilterX-XSS-Protection: 0）反例 5：Spring Security 默认 frameOptions DENY 但项目需要合法子域 iframe
sameOrigin 但未配真正需要的跨子域允许app.example.com 嵌 widget.example.com 的 iframe；Spring .frameOptions().sameOrigin() 不允许跨子域frame-ancestors 'self' https://widget.example.com反例 6：HSTS preload list 已提交但 header 未标 preload
preload 关键字Strict-Transport-Security: max-age=31536000; includeSubDomains（缺 preload）preload 关键字反例 7：Cross-Origin-Resource-Policy 缺失导致 CORS 旁路
Allow-Origin: https://app.example.com，但未配 CORP；恶意 origin 可用 <script src="..."> 触发资源加载侧信道same-origin 或 same-site反例 8：Nginx add_header 不继承导致部分 location 漏 header
add_header 不向子 location 继承，子 location 重新 add_header 后外层 add_header 全失效server { add_header X-Frame-Options DENY always; } location /api { add_header Cache-Control no-store; } → /api 路径下所有外层 add_header 失效include /etc/nginx/conf.d/security-headers.conf 在每个 location 引入白盒底线：不假装看到看不到的代码。
下面这些情形数据流分析无法继续追踪，必须标 static-unknown：
CDN / 反向代理边缘规则——Cloudflare Workers / CloudFront Functions / Fastly VCL / 边缘节点 Transform Rules。代码仓库内看不到边缘配置时必须独立读 infra 仓库 / 控制台导出；不能默认应用层观察等于浏览器实际收到的 header。处置：标 static-unknown 记录"边缘配置未审"。
动态 header 决策——基于 User-Agent / 地域 / feature flag / A/B 实验切换 header 值。处置：每个分支独立审计；不能只看一个分支结论。
WebSocket 握手响应 header（HTTP upgrade）——WebSocket 升级响应不在本能力评估范围（浏览器对 WS 不应用大多数安全 header）。处置：明确标 本能力 n/a (WebSocket upgrade)。
CSP 细节策略分析——directive 分解 / unsafe-inline 风险 / source-list 收敛 / nonce 配置 → 全部转 csp-audit。处置：本 skill 只判 CSP 声明存在性；细节不在本能力范围。
闭源中间件 / 三方 SDK 内部 header 操作——第三方 SDK 可能在内部修改响应 header。处置：标 static-unknown 推 dependency-decompile 反编译验证。
运行时配置中心（Apollo / Nacos / 配置文件热加载）——header 值由远程配置中心动态下发。处置：读取实际生效配置；标 static-unknown 直到配置来源确认。
反向代理保留头（preserve_host / proxy_pass_header）——代理是否透传 upstream 已设的 header，取决于代理配置。处置：核对代理配置 proxy_pass_header / proxy_hide_header。
底线：写"所有安全 header 已合规"前，所有 static-unknown 单元格必须显式列出原因。否则结论降级 partial-coverage。
helmet；Spring Security → .headers().* 完整配置；Django → SecurityMiddleware + django-csp；Rails → secure_headers gem；Go → unrolled/secure| Header | 推荐值 |
|---|---|
Strict-Transport-Security | max-age=31536000; includeSubDomains; preload（提交 preload list） |
X-Frame-Options | DENY（或用 CSP frame-ancestors 'self'） |
X-Content-Type-Options | nosniff |
Referrer-Policy | strict-origin-when-cross-origin（或更严 no-referrer） |
Permissions-Policy | 显式禁用不需要的能力，如 camera=(), microphone=(), geolocation=(), payment=() |
Cross-Origin-Opener-Policy | same-origin |
Cross-Origin-Embedder-Policy | require-corp（若需启用跨源隔离） |
Cross-Origin-Resource-Policy | same-origin 或 same-site |
Content-Security-Policy | 见 csp-audit |
X-XSS-Protection | 不声明（或 0），已废弃 |
gatewayResponses 对 DEFAULT_4XX / DEFAULT_5XX 单独配include /etc/nginx/conf.d/security-headers.conf 在每个 location 引入，规避 add_header 不继承陷阱