Security Baseline 是一个与技术栈无关的安全基线技能，用于为任何生产网站或 Web 应用建立安全底线，涵盖公开发布前应具备、发布后需定期验证的安全事项。
用途 该技能适用于以下场景：上线前安全审查；搭建新站点或环境；定期安全审计（建议每季度一次）；接入新供应商或第三方集成；响应安全发现或报告；事件后加固。不适用于：正在进行的事件响应（应使用 incident-response）、代码级安全审查（应使用 code-review-web）、邮件认证 SPF/DKIM/DMARC（应使用 email-deliverability）、DNS 层安全如 CAA、DNSSEC（应使用 domain-strategy）、性能相关安全如 DDoS 防护规模评估（应使用 performance-optimization）。
所需输入 使用该技能需要提供：范围内的站点或应用（URL、环境）；托管平台与 CDN；认证方式（如有）；第三方脚本与集成；合规背景（PCI、SOC2、GDPR 等，如适用）；现有安全工具。
六层框架 安全是分层的，每层应对不同的攻击面。
第一层：传输安全。数据如何从服务器传到客户端。要求全站 HTTPS，不允许 HTTP 变体提供内容；最低 TLS 1.2，优先 TLS 1.3，禁用 TLS 1.0 和 1.1；设置 HSTS 头，高可信站点加上 includeSubDomains 和 preload；仅使用强密码套件；证书来自受信任 CA 并监控到期。
第二层：响应头。告诉浏览器关于站点的信息，包括 Strict-Transport-Security、Content-Security-Policy、X-Content-Type-Options、X-Frame-Options、Referrer-Policy、Permissions-Policy、Cross-Origin-Opener-Policy、Cross-Origin-Embedder-Policy 等，并给出各自用途与默认值建议。
第三层：认证与授权。用户如何证明身份与可执行操作：强密码要求（重长度而非复杂度规则，允许长口令）；登录账户锁定或限流；提供 2FA，管理员账户必须启用；会话令牌短时效、安全、HttpOnly Cookie；登出在服务端失效令牌；密码重置流程不暴露账户是否存在；每个请求都检查授权，不依赖 UI 隐藏。
第四层：输入处理。服务端校验（客户端校验只是 UX）；数据库访问使用参数化查询，禁止字符串拼接 SQL；按上下文做输出编码（HTML、JS、URL、CSS）；文件上传限制（类型、大小、位置、扫描）；易被滥用端点限流；状态变更请求加 CSRF 令牌。
第五层：密钥管理。不在代码、仓库配置文件或镜像环境变量中存放密钥；使用专用密钥管理器；不同环境使用不同密钥；记录并执行轮换计划；密钥访问审计日志；缩小影响范围，每个服务独立且范围受限的凭证。
第六层：运营安全。团队如何运作：季度审查访问控制，离职立即回收权限；所有管理员账户（托管、DNS、注册商、代码托管、部署工具）强制 2FA；启用并审查审计日志；漏洞扫描（依赖、容器、基础设施）；定义补丁节奏；具备事件响应手册；备份存在并经过测试；发布安全联系人（/.well-known/security.txt）。
内容安全策略（CSP） CSP 是最强大也最常被错误配置的响应头。它告诉浏览器各类资源（脚本、样式、图片、框架、连接等）允许的来源。严格 CSP 即使在输入处理有缺陷时也能阻止大多数 XSS。两种风格：严格 CSP（推荐）使用基于 nonce 或 hash 的来源白名单，内联脚本必须通过 nonce 显式允许；白名单 CSP（传统）列出允许域名，更易设置但更弱。严格 CSP 需要应用改动，但回报可观。CSP 应逐步推出：先用 Content-Security-Policy-Report-Only 记录违规而不阻断，设置违规报告端点，观察合理违规，调整策略，待误报减少后切换到强制模式，并持续监控。常见错误：script-src 中 unsafe-inline、unsafe-eval、通配符来源、允许托管任意用户内容的 CDN、未限制 frame-ancestors。
工作流 第一步：运行基线扫描，使用免费扫描工具如 securityheaders.com 或 MDN HTTP Observatory，获取当前评分；若无法获得扫描结果，按数据可用性规则说明缺口。第二步：清点攻击面，包括域名与子域名、公开端点、认证入口、管理界面、第三方集成及其权限。第三步：逐层审计，记录已到位项、缺失项、风险等级（高、中、低）。第四步：排序，高风险易修复项优先（如未设 HSTS、缺默认头、管理员无 2FA、启用旧 TLS），其次中风险中修复项（CSP 推出、输入校验缺口、密钥管理改进），最后低风险锦上添花项。第五步：实施并验证，每项修复在非生产环境测试，用扫描器验证，再上线并复验。第六步：建立监控，包括证书到期告警、CSP 违规报告、登录失败监控、异常管理员活动告警、依赖漏洞告警。第七步：记录基线文档，说明每个站点应满足的必需头、必需配置、必需实践，新站点据此审计，现有站点定期复审。第八步：安排复审，季度是底线，重大变更或事件后追加复审。
合规触点 非法律建议。PCI DSS（处理支付卡）远比基线复杂，基线只是起点而非充分；SOC 2 与大多数 CC 控制（CC6 系列）对齐，需文档化基线与执行证据；GDPR/隐私法规支持安全义务（第 32 条），但隐私范围大于安全；HIPAA、HITRUST、FedRAMP 基线必要但远不充分，需专门帮助。
常见失败模式 HSTS 未加 includeSubDomains；HSTS preload 未做长期承诺；CSP 含 unsafe-inline；缺少默认头；管理员无 2FA；密钥烘入镜像环境变量；缺少 security.txt；启用旧 TLS；CDN 因 CSP 配置不当允许任意内联脚本；无事件响应计划；漏洞扫描不修复；渗透测试结果被忽视。
输出格式 安全基线文档包括：清点（范围）、逐层状态、必需头及取值（按环境）、必需配置（TLS、密钥、认证）、必需运营实践、按优先级排列的发现、修复计划（负责人、日期）、再审计节奏。
数据缺口规则 该技能输出依赖其无法自行生成的数据、测量或工具结果。当所需输入、工具或数据源不可用或无法验证时，合规输出是交付物并声明缺口：需要什么、实际获得或验证了什么、影响输出哪些部分。不得为完成交付而编造、估算或插值。声明的缺口本身就是完整答案。
参考文件 references/headers-checklist.md：按重要层级组织的推荐安全响应头复制粘贴清单，含示例值。