XSS 防护是什么
跨站脚本（XSS）防护检测请求参数与响应内容中的脚本特征，防止攻击者把脚本注入页面并在其他用户浏览器中执行。防护需要两层配合：WAF 在请求侧拦截明显的注入payload，应用侧做输出编码与内容安全策略（CSP）响应头，从根上限制脚本执行。只靠 WAF 拦截变体太多的写法并不可靠，尤其是存储型 XSS 在写入时可能看起来是正常文本。
基本信息
| 检测对象 | 请求参数中的脚本特征与响应内容中的可疑脚本 |
|---|---|
| 可用动作 | 阻断恶意请求、对可疑响应做标记或转义 |
| 应用侧配合 | 输出编码、CSP 与 X-Content-Type-Options 等安全响应头 |
| 变体风险 | 反射型、存储型与基于 DOM 的变体编码方式各异 |
| 上线方式 | CSP 先用报告模式观察，避免直接阻断现有内联脚本 |
典型使用场景
- 留言与评论功能：存储型 XSS 的主要入口
- 搜索与回显页面：反射型 XSS 的常见位置
- 富文本编辑器：需要平衡功能与安全，规则单独放宽
- 单页应用：前端渲染带来 DOM 型风险，需前后端配合
- 合规整改：按测评项要求部署安全响应头与检测能力
响应头加固示例
响应头加固示例
add_header Content-Security-Policy "default-src 'self'; script-src 'self'" always;
add_header X-Content-Type-Options nosniff always;
# 上线先用报告模式观察，确认未阻断既有脚本后再切换强制模式
add_header Content-Security-Policy-Report-Only "default-src 'self'" always;防护要点
| 要点 | 做法 | 风险 |
|---|---|---|
| 请求侧检测 | 对参数中的脚本特征拦截 | 变体多，仅靠特征不可靠 |
| 输出编码 | 按上下文做 HTML/JS 编码 | 编码位置错误仍可被利用 |
| CSP | 限制脚本来源，先报告后强制 | 直接强制可能阻断既有脚本 |
| 富文本处理 | 白名单标签与属性 | 过度放宽等于开放注入点 |
| 监控与复核 | 关注告警中的参数与页面 | 误报长期不处理会掩盖真实攻击 |
CSP 上线先用报告模式（Content-Security-Policy-Report-Only）观察：直接开强制模式可能阻断既有内联脚本，导致页面功能异常，回退又要重新走流程。