fastcgi本身不处理安全头，必须由nginx在响应返回客户端前统一注入add_header ... always，覆盖所有路径（含php动态内容、错误页、重定向），禁用php重复输出，确保x-content-type-options、csp、x-frame-options等关键头不被绕过或冲突。
FastCGI 本身不处理安全头，它只是 Nginx 与 PHP（或其他后端）之间传输数据的协议。真正起防御作用的是 Nginx 层统一输出的安全响应头——这些头必须在 FastCGI 响应返回给客户端前，由 Nginx 主动添加并覆盖所有路径（含 PHP 动态内容、错误页、重定向等）。关键在于：不能依赖 PHP 输出安全头，否则极易被绕过或覆盖。
必须由 Nginx 统一注入，禁用 PHP 重复输出
PHP 应用（如 WordPress、Laravel）常自带 CSP 或 X-Frame-Options 输出逻辑，这会导致策略冲突或失效。务必在 Nginx 配置中强制接管：
- 在
http或server块顶层使用add_header ... always，确保所有响应（包括 404、500、.php 文件、/index.php 重写路径）都携带安全头 - 检查 PHP 配置：关闭
expose_php off，并在 php.ini 中禁用自动头（如移除header("X-Content-Type-Options: nosniff")类代码） - 验证是否生效：用
curl -I https://yoursite.com/index.php查看响应头，确认只有 Nginx 输出，无重复或缺失
针对 PHP 动态内容强化 CSP 策略
PHP 页面常含内联脚本、动态 eval 或第三方插件加载，需针对性收紧：
- 禁用高危指令：
script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'; form-action 'self' - 彻底移除
'unsafe-inline'和'unsafe-eval'；若业务必需内联 JS，改用nonce方式（后端渲染时生成唯一值，Nginx 配置中同步引用） - 对上传目录（如
/uploads/）或用户可写路径，单独配置更严策略：default-src 'none'; script-src 'none'; style-src 'none'; img-src 'self' data:
FastCGI 场景下必须加固的配套头
仅靠 CSP 不够，以下头需与 FastCGI 请求流协同生效：
-
X-Content-Type-Options: nosniff —— 防止浏览器将
text/plain的 PHP 错误页误解析为 JS 执行 - X-Frame-Options: DENY 或 SAMEORIGIN —— 阻断攻击者把 PHP 登录页嵌入恶意 iframe 实施点击劫持
- Referrer-Policy: strict-origin-when-cross-origin —— 避免 PHP 接口跳转时泄露敏感参数到第三方站点
- Strict-Transport-Security —— 强制 HTTPS，防止 FastCGI 通信中间被降级劫持
规避常见陷阱
FastCGI 环境下容易忽略的细节：
- 错误页（如 502 Bad Gateway）默认不继承 FastCGI location 的 header，必须在
http块全局加always，或在error_page对应 location 中显式补全 - PHP 的
fastcgi_param不影响响应头，但若用了fastcgi_hide_header，会意外屏蔽 Nginx 添加的头，应删除该指令 - 开启
gzip_vary on时，确保安全头不被缓存代理错误覆盖；建议搭配Cache-Control: no-store用于敏感 PHP 接口
