CSP是HTTPS下阻断XSS等攻击的关键防线，需先用Report-Only模式采集3–7天日志，再启用严格策略；必须全局配置、禁用unsafe-inline、使用nonce或hash、覆盖所有响应类型，并对API、上传目录和错误页做差异化加固。
HTTPS 本身只保障传输过程不被窃听或篡改，但无法阻止页面加载并执行恶意脚本。CSP 是 HTTPS 环境下必须补上的关键防线——它由浏览器强制执行白名单规则，从源头阻断 XSS、恶意资源注入等攻击。
先用 Report-Only 模式观察真实行为
上线严格策略前，切忌直接启用 Content-Security-Policy 阻断模式。应先用报告模式收集真实流量中的违规行为：
- 在
http或server块中添加：add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' https:; img-src 'self' data: https:; style-src 'self' 'unsafe-inline'; connect-src 'self' https:; report-uri /csp-report;" always; - 部署后持续采集 3–7 天日志，重点关注哪些内联脚本、CDN 域名、
eval调用是业务必需的 - 确认无误后再将
Content-Security-Policy-Report-Only替换为Content-Security-Policy，并逐步移除高危指令
禁用 unsafe-inline，改用 nonce 或 hash
允许 'unsafe-inline' 会让 CSP 大幅失效。生产环境必须替换为可控方式：
- 后端为每个 HTML 响应生成唯一 base64 nonce（如
nonce="Xa9fLm2p"），注入到<script nonce="Xa9fLm2p"> - Nginx 配置中同步写入该值：
add_header Content-Security-Policy "script-src 'self' 'nonce-Xa9fLm2p' https://cdn.example.com; default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self';" always; - 若无法改造后端，可对内联脚本内容计算 SHA256 hash，写入
script-src 'sha256-xxx'
确保所有响应都携带 CSP，不留防护盲区
CSP 必须覆盖全部 HTTP 响应，包括错误页、重定向、静态资源（.js/.css/.svg）——否则攻击者可绕过：
- 所有
add_header必须加always参数，例如：add_header Content-Security-Policy "default-src 'none'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data:; font-src 'self'; connect-src 'self'; base-uri 'self'; form-action 'self';" always; - 统一在
http或server级别配置，避免多个location块重复定义导致覆盖 - 检查 PHP/Node.js/Java 等后端是否也输出 CSP 头，如有必须关闭，只由 Nginx 单一源头管理
针对 API 和敏感路径做差异化加固
非 HTML 页面无需执行脚本，可大幅降低攻击面：
- 在
location /api/中单独配置更严策略：add_header Content-Security-Policy "default-src 'none'; script-src 'none'; object-src 'none'; base-uri 'none'; form-action 'none';" always; - 上传目录（如
/upload/）禁止执行脚本：add_header Content-Security-Policy "script-src 'none'; object-src 'none';" always; - 错误页（404/500）也要显式设置 CSP，防止攻击者利用空白页注入
