防范XSS需在HTML输出时用htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8')转义，JS字符串内用json_encode()，配合CSP头限制脚本执行，并对富文本使用HTMLPurifier等专业库过滤。
输出用户数据前必须用 htmlspecialchars() 转义
XSS 最常见入口是把用户输入（如 URL 参数、表单提交内容）直接 echo 到 HTML 页面里。不加处理就输出，攻击者塞进 就会执行。
正确做法是在所有动态输出到 HTML 上下文的地方调用 htmlspecialchars()，且明确指定编码和引号风格：
- 始终传入
ENT_QUOTES和UTF-8：htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8') - 不要依赖默认参数——PHP 旧版本默认不转义单引号，
- 如果输出在 JavaScript 字符串内（比如
var msg = "";），htmlspecialchars()不够用，得用json_encode($user, JSON_UNESCAPED_UNICODE)并确保外层引号匹配
使用 Content-Security-Policy 头限制脚本执行
即使某处漏了转义，CSP 能大幅降低 XSS 危害。它告诉浏览器：“只允许执行我白名单里的脚本”。
关键配置项要写全：
立即学习“PHP免费学习笔记（深入）”；
- 禁止内联脚本：
Content-Security-Policy: script-src 'self'—— 这样和onclick=...全部失效 - 禁用
eval类危险函数：script-src 'self' 'unsafe-eval'中去掉'unsafe-eval' - 避免宽泛值：
'unsafe-inline'或*直接废掉 CSP 效果 - PHP 中设置：
header("Content-Security-Policy: script-src 'self'; object-src 'none'; base-uri 'self';");
表单提交和 URL 参数需双重过滤：入库前验证 + 输出前转义
有人觉得“我数据库里存的是干净的，所以输出时不用再处理”，这是典型误区。XSS 不只发生在输出环节，还可能来自：
- 其他系统导入的数据（比如 CSV 批量导入没过滤）
- 管理员后台误存了未转义内容
- 缓存层返回了旧的、未转义的 HTML 片段
所以原则是：存储时做最小化验证（比如邮箱只留字母数字@.），但绝不信任存储内容；每次输出都重新转义。不要省略任何一次 htmlspecialchars() 调用。
警惕富文本场景下的特殊处理
如果网站允许用户发带格式的内容（如后台编辑器、评论支持 HTML），htmlspecialchars() 会把所有标签都转成文本，显然不行。
这时不能手写正则过滤，应使用成熟库：
-
HTMLPurifier：最严格，可配置白名单标签和属性，适合对安全性要求高的场景 -
strip_tags()配合白名单字符串（如strip_tags($html, '）仅作临时应急，无法防')
- 永远不要用
preg_replace()去“删掉 script 标签”——绕过方式太多，比如大小写混写、注释干扰、Unicode 编码等
富文本的解析和渲染链路长，容易漏掉 style 属性、data-* 属性、SVG 中的 script，这些细节比主逻辑更易出问题。
