学习目标：通过“Content Security Policy：从 Report-Only 到逐步收紧”掌握可在真实项目里复用的工程方法。本文不只解释概念，还给出环境要求、实施顺序、代码/配置、验证方法和故障排查。
适用场景与前置条件
仅在自有或获授权环境验证；准备依赖清单、响应头、认证流程和权限模型。本文只讨论防护、审计和修复。
如果这是第一次接触该主题，建议先在独立测试环境完成一遍完整流程，再把变更拆成小步骤进入真实项目。重要配置和数据修改都应先有备份或可恢复版本。
核心知识地图
- 输入验证降低异常数据进入系统的概率，输出编码防止数据被浏览器解释成代码。
- 参数化查询把 SQL 结构与数据分离，是防 SQL 注入的核心措施。
- CSRF 防护依赖 SameSite、Token、来源校验等组合，不等同于 CORS。
- CSP、最小权限、MFA、会话轮换和依赖更新构成纵深防御。
实施步骤
- 步骤 1：先画出信任边界：浏览器、API、数据库、第三方服务和管理员操作。
- 步骤 2：对每个入口定义允许的数据类型/长度/格式，默认拒绝未知字段。
- 步骤 3：数据库全部使用参数化查询，模板按上下文输出编码。
- 步骤 4：从 CSP Report-Only、安全 Header 和依赖扫描收集真实问题。
- 步骤 5：修复后加入自动测试/安全检查，并记录残余风险与升级计划。
代码 / 配置演示
下面的片段使用示例域名、测试数据和非真实凭据，重点展示结构与验证方式。复制到项目后，要根据当前版本的官方文档调整参数。
# Start with Report-Only, observe legitimate dependencies, then tighten.
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
# After validation, migrate the CSP header from Report-Only to enforcing mode.
如何验证结果
不要只看“页面能打开”或“命令没有报错”。验证应至少包含三个维度：一是功能结果是否符合预期；二是日志、状态码、查询计划或指标能否证明请求走了正确路径；三是失败场景是否会返回明确错误并保持系统可恢复。对上线变更，建议记录变更前后数据，便于回归比较。
常见问题与排错
- 把前端校验当成安全边界，服务端完全信任请求。
- 拼接 SQL 或 HTML 字符串处理不可信输入。
- 会话 Cookie 缺少 Secure/HttpOnly/SameSite。
- 漏洞扫描发现问题后只隐藏错误，不修复根因。
如果问题仍然存在，按配置 → 运行时 → 网络/依赖 → 数据 → 缓存的顺序逐层缩小范围。每次只改变一个主要变量，并保留失败日志；一次同时改多处会让真正原因更难确认。
上线检查清单
- 版本和依赖已确认，示例配置没有直接复制生产密码或 Token。
- 关键路径有可重复的验证命令、自动测试或健康检查。
- 日志能定位一次请求/任务，且不会记录密码、Cookie、Token 等敏感值。
- 数据库、配置、证书或部署变更有备份和回滚步骤。
- 已阅读当前版本的官方文档，确认没有依赖过时 API 或废弃配置。
总结
“Content Security Policy：从 Report-Only 到逐步收紧”的价值不在于记住某一段命令，而在于建立稳定的判断流程：明确边界、做最小验证、观察真实运行结果、处理失败路径，再把验证固化为测试和文档。这样即使框架或版本变化，也能快速判断哪些部分需要调整。