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 等）
• 现有安全工具

---

框架：6 个层面

安全防护是分层的。每一层针对不同的攻击面。

第 1 层：传输安全

数据从服务端传输到客户端的方式。

• 全站使用 HTTPS。不得通过任何 HTTP 变体提供内容。
• 最低使用 TLS 1.2，优先使用 TLS 1.3。禁用 TLS 1.0 和 1.1。
• 设置 HSTS（Strict-Transport-Security）标头；对于可信度高的网站，添加 includeSubDomains 和 preload。
• 仅使用强密码套件。只要从服务提供商处选择现代配置，现代浏览器就能妥善处理。
• 使用受信任 CA 颁发的证书，并监控证书过期情况。

第 2 层：响应标头

告知浏览器有关网站的信息。

标头	用途	默认值
Strict-Transport-Security	强制使用 HTTPS	max-age=31536000; includeSubDomains
Content-Security-Policy	限制资源加载	依网站而定
X-Content-Type-Options	防止 MIME 嗅探	nosniff
X-Frame-Options	防止点击劫持	DENY 或 SAMEORIGIN
Referrer-Policy	控制引荐来源信息	strict-origin-when-cross-origin
Permissions-Policy	控制浏览器功能	依网站而定（摄像头、麦克风等）
Cross-Origin-Opener-Policy	进程隔离	same-origin（兼容时）
Cross-Origin-Embedder-Policy	跨源限制	require-corp（适用时）

CSP 值得单独关注。请参阅下方的框架部分。

第 3 层：身份验证和授权

用户证明身份以及确认其操作权限的方式。

• 设置强密码要求（优先考虑长度，而非复杂度规则；允许使用较长的密码短语）
• 对登录设置账户锁定或速率限制
• 提供双重身份验证（2FA），并要求管理员账户启用
• 会话令牌应有效期短，并存储在安全的 HttpOnly Cookie 中
• 注销时应在服务端使令牌失效，而不只是客户端
• 密码重置流程不得泄露账户是否存在
• 每次请求都检查授权（不要依赖隐藏 UI）

第 4 层：输入处理

处理不可信输入的方式。

• 在服务端进行验证（客户端验证是为了改善用户体验，而非安全防护）
• 任何数据库访问都使用参数化查询（不得将字符串拼接到 SQL 中）
• 根据上下文进行输出编码（HTML、JS、URL、CSS）
• 限制文件上传（类型、大小、位置、扫描）
• 对可能遭滥用的端点实施速率限制
• 对会更改状态的请求使用 CSRF 令牌

第 5 层：机密管理

凭据和密钥的存放位置。

• 不得将机密放在代码、仓库中的配置文件或构建到镜像中的环境变量里
• 使用专用的机密管理器存储机密
• 不同环境使用不同机密（不得共用开发环境和生产环境的机密）
• 记录并遵循轮换计划
• 记录机密访问审计日志
• 限制影响范围（每项服务使用独立凭据，并严格限定权限）

第 6 层：运营安全

团队的运营方式。

• 每季度审查访问控制（人员离职时立即撤销访问权限）
• 强制所有管理员账户启用 2FA（托管服务、DNS、注册商、代码托管平台、部署工具）
• 启用并审查审计日志
• 漏洞扫描（依赖项、容器、基础设施）
• 明确补丁更新周期
• 编写事件响应手册（参见 incident-response）
• 备份已就绪并经过测试（参见 backup-and-disaster-recovery）
• 公布安全联系信息（位于 /.well-known/security.txt 的 security.txt）

---

内容安全策略

CSP 是功能最强、也最常配置错误的响应头，值得单独介绍。

CSP 的作用

CSP 会告知浏览器，各类资源（脚本、样式、图片、框架、连接等）允许从哪些来源加载。即使输入处理存在漏洞，严格的 CSP 也能阻止大多数 XSS 攻击。

两种形式

严格 CSP（推荐）： 使用基于 nonce- 或 hash- 的来源允许列表。必须通过 nonce 明确允许内联脚本。

Content-Security-Policy: script-src 'self' 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'self';

允许列表 CSP（旧式）： 列出允许的域名。更易配置，但防护能力弱得多。

Content-Security-Policy: script-src 'self' https://trusted.com; ...

严格的 CSP 需要修改应用（每个内联脚本都需要 nonce）。这项投入值得。

逐步推出 CSP

1. 从 Content-Security-Policy-Report-Only 开始，只记录违规情况，不进行拦截。
2. 设置违规报告端点。
3. 留意合理的违规情况（第三方脚本、内联处理程序）。
4. 调整策略。
5. 当违规情况大多属于误报时，切换到强制执行模式。
6. 继续监控违规报告，发现新问题。

常见的 CSP 错误

• 在 script-src 中使用 unsafe-inline。这会使 CSP 的大部分价值荡然无存。
• 在 script-src 中使用 unsafe-eval。旧版库经常需要它；应重构或替换这些库。
• 使用通配符来源（*）。这会使策略失效。
• 允许托管任意用户内容的 CDN。攻击者可以向 CDN 上传脚本。
• 不限制 frame-ancestors。使用它防御点击劫持（比 X-Frame-Options 更灵活）。

---

工作流程

步骤 1：运行基线扫描

使用免费扫描工具：securityheaders.com，或 MDN HTTP Observatory（developer.mozilla.org/en-US/observatory）。获取当前评级。这是最低基线。如果无法获取扫描结果，请根据数据可用性规则说明这一缺口。

步骤 2：盘点攻击面

• 范围内的域名和子域名
• 公共端点（表单、API）
• 身份验证入口
• 管理界面
• 第三方集成及其权限

步骤 3：审查各层

逐一检查这 6 层。对每一层记录：

• 已落实的措施
• 缺失的措施
• 风险级别（高、中、低）

步骤 4：确定优先级

优先处理高风险、易修复的问题：

• 未设置 HSTS
• 缺少默认响应头
• 管理员未启用 2FA
• 启用了旧版 TLS

接下来处理中等风险、修复难度适中的问题：

• 推出 CSP
• 输入验证缺口
• 改进密钥管理

最后处理低风险、锦上添花的事项：

• 优化 Permissions-Policy
• 可选响应头（Cross-Origin-* 系列）

步骤 5：实施并验证

针对每项修复：

• 进行更改
• 在非生产环境中测试
• 使用扫描工具验证
• 推出更改
• 在生产环境中再次验证

步骤 6：设置监控

• 证书到期提醒
• CSP 违规报告
• 失败登录监控
• 异常管理员活动提醒
• 依赖项漏洞提醒（Dependabot、Snyk 或同类工具）

步骤 7：记录基线

编写安全基线文档，说明每个站点都应具备的内容：

• 必需的响应头
• 必需的配置
• 必需的实践

新站点需依据此文档进行审查。现有站点需定期重新审查。

步骤 8：安排审查

每季度审查是最低要求。重大变更或安全事件发生后，也应增加审查。

---

常见合规要点

这不是法律建议。以下是安全基线与合规要求交汇的领域：

• PCI DSS（如果处理支付卡）：涉及的内容远多于安全基线。安全基线只是起点，并不足以满足要求。
• **SOC 2：**安全基线与大多数 CC 控制措施（CC6 系列）相符。审计要求提供已记录的安全基线以及执行证据。
• **GDPR / 隐私法规：**安全基线有助于履行安全义务（第 32 条）。隐私的范围比安全更广。
• **HIPAA、HITRUST、FedRAMP：**安全基线是必要条件，但远远不够。请寻求专业帮助。

适用合规要求时，安全基线是必要条件，但不是完整答案。

---

常见故障模式

**HSTS 未配置 includeSubDomains。**攻击者会诱使浏览器通过 HTTP 访问尚未启用 HTTPS 的子域名。

**未做好长期准备就启用 HSTS 预加载。**预加载后，要等 Chrome 更新将其传递给用户，移除可能需要数月，而且无法保证其他浏览器也会更新。只有在所有子域名都能永久稳定使用 HTTPS 后，才启用预加载。

**CSP 配置了 unsafe-inline。**这会让 CSP 的大部分保护失效。要么采用严格策略（基于 nonce），要么接受 CSP 只能提供有限保护这一事实。

缺少默认安全标头。X-Content-Type-Options、X-Frame-Options、Referrer-Policy 实施简单且免费。请配置这些标头。

**管理员账户未启用双重身份验证。**这是小型团队中最常见、影响最大的漏洞。今天就修复。

**将密钥作为环境变量写入镜像。**任何能访问镜像的人都能获取这些密钥。请使用运行时密钥管理器。

**没有 security.txt。**研究人员发现问题后，需要有地方提交报告。请在 /.well-known/security.txt 发布 security.txt。

**启用了旧版 TLS。**请禁用 TLS 1.0 和 1.1。大多数服务提供商都提供一个复选框来完成此操作。

**CDN 因 CSP 配置错误而允许任意内联脚本。**CDN 会代理用户内容，攻击者会利用这一点。请根据实际加载的资源审查 CSP。

**没有事件响应计划。**当（而不是是否）发生安全事件时，没有操作手册就会一片混乱。请参阅 incident-response。

**只扫描漏洞，却不修复。**报告越积越多。如果没有人修复发现的问题，扫描就只是在做表面功夫。

**忽视渗透测试结果。**渗透测试报告被束之高阁。测试后不修复问题，比不做测试更糟糕。

---

输出格式

安全基线文档包括：

• **清单：**范围内的内容
• **逐层状态：**已落实和缺失的内容
• **必需标头：**包括取值，并按环境应用
• **必需配置：**TLS、密钥、身份验证
• **必需运维实践：**访问权限审查、补丁频率、审计日志记录
• **发现的问题：**按优先级排列的差距清单
• **修复计划：**负责人、日期
• **重新审计频率：**下次审查时间

---

所需数据不可用时

此技能的输出依赖其自身无法生成的数据、测量结果或工具结果。当所需的输入、工具或数据源不可用或无法核实时，获准的输出是交付成果，并明确说明差距：需要什么、实际获取或核实了什么，以及输出中哪些部分受到影响。绝不允许为了完成交付成果而编造、估算或插值所需数值。明确说明差距本身就是完整答案。

---

参考文件

• references/headers-checklist.md：可复制粘贴的推荐安全标头清单，包含示例值，并按重要程度分级。