为什么要写内部模板
除了使用官方模板库，团队可以按内部规范自己写模板，把单位特有的检查固化成可重复执行的检查项：内网服务的暴露路径、安全响应头缺失、特定中间件版本指纹、自定义接口的默认口令等。这样做的好处是经验不再停留在某个人的笔记里，而是变成扫描任务中可追溯的一条检查。
基本信息
| 工具 | nuclei（ProjectDiscovery），模板为 YAML 格式 |
|---|---|
| 模板结构 | id、info（名称与等级）、请求定义、匹配器 |
| 常用匹配器 | type word 与 type regex，配合 part 限定 header 或 body |
| 反向匹配 | negative: true 表示不匹配即命中，适合检查缺失项 |
| 调试方式 | -t 指定模板目录，-debug 查看请求与响应细节 |
| 管理要求 | 模板纳入版本管理，与扫描任务绑定版本号 |
模板要素与说明
| 要素 | 说明 | 注意 |
|---|---|---|
| id | 模板唯一标识 | 使用内部前缀，避免与官方模板冲突 |
| info | 名称、作者、等级 | 等级要与实际风险匹配 |
| path | 请求路径 | 避免写死域名，使用变量 |
| matchers | 匹配条件 | 用 part 限定在 header 或 body |
| negative | 不匹配时命中 | 适合检查响应头缺失等场景 |
| tags | 分类标签 | 便于按内部类别筛选运行 |
模板骨架示例（检查安全响应头缺失）
模板骨架示例（检查安全响应头缺失）
id: internal-security-headers
info:
name: HSTS 响应头缺失
author: sec-team
severity: low
tags: internal
http:
- method: GET
path:
- "{{BaseURL}}/"
matchers:
- type: word
part: header
words:
- "Strict-Transport-Security"
negative: true本地调试
本地调试
# 先跑单个模板确认语法与命中逻辑
nuclei -u https://internal.example.com -t ./my-templates/ -debug
# 确认命中一次后，再纳入例行扫描清单
nuclei -l targets.txt -t ./my-templates/ -rl 30 -o internal-headers.txt
# 模板文件纳入版本管理，扫描结果记录所用模板版本典型使用场景
- 把内部安全基线固化成可执行的检查项
- 内网服务暴露路径的例行核查
- 安全响应头与配置类基线检查
- 特定中间件或框架的版本指纹识别
- 新上线系统的快速合规检查
- 扫描结果可追溯：模板版本与结果绑定
内部模板建议放入版本管理，并与扫描任务绑定版本号。这样「本周检查列表」可追溯，结果出现差异时也能判断是目标变化还是模板调整。
匹配条件写得太宽松会产生大量误报，反而让例行检查失去可信度。新模板先在少量目标上验证命中率，再纳入全量任务。