在Apache中用mod_headers配置Content-Security-Policy是防御XSS最有效的手段之一,它不依赖前端代码,直接由服务器注入响应头,对HTML、JS、CSS、AJAX等所有资源统一生效,需确保mod_headers已启用,并在VirtualHost或主配置中全局设置,避免被覆盖。

在 Apache 中用 mod_headers 配置 Content-Security-Policy(CSP)是防御 XSS 最有效的手段之一。它不依赖前端代码,直接由服务器注入响应头,对所有资源类型(HTML、JS、CSS、AJAX 等)统一生效。
确保 mod_headers 已启用
该模块是设置 CSP 的前提,未启用则所有 Header 指令无效:
- Debian/Ubuntu 系统执行:
sudo a2enmod headers && sudo systemctl restart apache2 - RHEL/CentOS 系统检查
httpd.conf中是否已取消注释:LoadModule headers_module modules/mod_headers.so - 配置后可用
apache2ctl -M | grep headers或httpd -M | grep headers验证
在合适位置添加 CSP 头部指令
CSP 应尽量在全局或虚拟主机层级配置,避免被子目录或应用覆盖。推荐写在 <virtualhost></virtualhost> 块内或主配置文件(如 /etc/apache2/apache2.conf)中:
Apache Superset 是一个广泛采用的开源 BI 平台,用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时,此技能非常有用。
- 基础写法(仅允许同源资源):
Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self';" - 若需加载 CDN 脚本,显式声明:
script-src 'self' https://cdn.example.com 'unsafe-inline' 'unsafe-eval'; - 注意:
'unsafe-inline'和'unsafe-eval'会削弱防护效果,仅在确实无法重构时临时启用 - 不要在
.htaccess中用Header set覆盖已存在的 CSP,应先Header unset Content-Security-Policy再重新 set,否则可能产生重复头或策略冲突
针对 WordPress 或子目录的特殊处理
若根目录已设严格 CSP,而子目录(如 /wp-admin/)因内联脚本或动态 JS 报错,可在对应目录的 .htaccess 中单独重置:
- 进入
/wp-admin/目录,新建或编辑.htaccess - 加入以下两行(移除继承的 CSP,再设更宽松策略):
Header unset Content-Security-PolicyHeader always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline';" - 该方式不影响主站安全水位,只局部放宽管理后台所需能力
验证与调试要点
配置完成必须验证,浏览器不会报错但策略可能未生效:
- 用浏览器开发者工具 → Network → 刷新页面 → 查看响应头中是否存在
Content-Security-Policy - 访问 securityheaders.com 输入域名自动检测
- 若策略未出现,常见原因有:模块未启用、配置未被加载(检查
a2ensite或Include路径)、被 PHP 或反向代理(如 Nginx 做前置代理)覆盖 - 测试阶段可加
report-uri或report-to指令收集违规事件,例如:default-src 'self'; report-uri /csp-report-endpoint










