在Web应用的攻防战场上，前端作为用户与服务器交互的第一道界面，时刻面临着XSS、代码注入等攻击威胁。内容安全策略（Content Security Policy，CSP）就像是为前端打造的一道隐形盾牌，通过精准的HTML配置，能从根源上大幅降低恶意代码的执行风险。
📚 什么是CSP？
CSP是一种安全标准，它通过浏览器的内置机制，限制页面可以加载的资源类型和来源，本质上是建立一套”白名单”机制。只有在白名单内的资源才能被浏览器加载和执行，从而阻止未经授权的脚本、样式、图片等资源运行，从源头切断XSS攻击的传播路径。
🛠️ 如何在HTML中配置CSP？
CSP的配置主要有两种方式：通过HTML的<meta>标签，或者通过HTTP响应头。对于前端开发者来说，<meta>标签配置更直观，适合在静态页面中快速测试和部署。
基础配置示例
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; script-src 'self' https://trusted-script.com; style-src 'self' 'unsafe-inline';">这段配置的含义是：
default-src 'self'：默认情况下，所有资源只能从当前域名加载script-src 'self' https://trusted-script.com：脚本文件只能从当前域名或指定的可信域名加载style-src 'self' 'unsafe-inline'：样式文件允许从当前域名加载，同时允许内联样式（出于兼容性考虑）
常见指令解析
default-src：所有资源的默认加载规则，其他资源类型的规则会覆盖此默认值script-src：JavaScript脚本的加载规则style-src：CSS样式表的加载规则img-src：图片资源的加载规则font-src：字体文件的加载规则connect-src：AJAX、WebSocket等网络请求的规则frame-src：嵌入的iframe资源规则
🚀 CSP的进阶实践
严格模式与兼容性平衡
在配置CSP时，需要在安全性和兼容性之间找到平衡点。比如'unsafe-inline'和'unsafe-eval'这两个指令，虽然会降低安全性，但在处理遗留代码或第三方库时可能暂时需要使用。建议逐步移除对这两个指令的依赖，采用非内联脚本和样式，以及避免使用eval()函数。
报告模式（Report-Only）
在正式部署严格的CSP规则之前，可以先使用报告模式测试，不会阻止资源加载，只会将违反规则的行为报告到指定地址：
<meta http-equiv="Content-Security-Policy-Report-Only" content="default-src 'self'; report-uri /csp-violation-report-endpoint;">哈希与非ce（Nonce）验证
对于必须使用的内联脚本或样式，可以通过哈希值或随机生成的Nonce来授权，无需使用'unsafe-inline'：
<!-- 使用哈希值 -->
<meta http-equiv="Content-Security-Policy" content="script-src 'sha256-abc123...';">
<!-- 使用Nonce -->
<meta http-equiv="Content-Security-Policy" content="script-src 'nonce-随机字符串';">
<script nonce="随机字符串">
// 内联脚本内容
</script>
🎯 CSP的实际防御效果
配置完善的CSP能有效防御以下常见攻击：
- 存储型XSS攻击：阻止恶意脚本的执行
- 反射型XSS攻击：过滤未经授权的脚本注入
- 点击劫持攻击：通过
frame-ancestors指令限制页面被嵌入的iframe来源 - 恶意资源加载：阻止从不可信域名加载的图片、脚本等资源
💡 配置CSP的注意事项
- 逐步迁移：不要一次性从无CSP直接切换到严格模式，建议先使用报告模式收集规则，再逐步收紧策略
- 第三方资源处理：确保所有第三方CDN、广告脚本、统计代码都被添加到白名单中
- 测试覆盖：在不同浏览器和设备上测试CSP配置，避免出现资源加载失败的情况
- 日志监控：定期查看CSP违规报告，及时调整规则，同时也能发现潜在的攻击尝试
🔚 结语
CSP并不是前端安全的”银弹”，但它是构建纵深防御体系中不可或缺的一环。通过合理的HTML配置，CSP能大幅提升Web应用的安全性，将攻击风险降到最低。在如今Web威胁日益复杂的环境下，掌握CSP的配置和实践，已经成为前端开发者的必备技能。
