必须显式传参htmlspecialchars($str, ENT_QUOTES, 'UTF-8')，因无参调用仅转义双引号，单引号属性可被绕过；ENT_QUOTES确保单双引号均转义，UTF-8防止多字节编码绕过。
所有用户数据输出到 HTML 页面前，必须用 htmlspecialchars() 显式传参处理，否则 XSS 几乎必然发生。
为什么 htmlspecialchars() 必须带三个参数
无参调用 htmlspecialchars($str) 只转义双引号，单引号属性（如 value='<?php echo $user; ?>'）可被绕过；htmlentities() 会把中文、emoji 全部转成实体，破坏内容可读性且不可逆；而 htmlspecialchars($str, ENT_QUOTES | ENT_HTML5, 'UTF-8') 才是安全底线：
-
ENT_QUOTES同时转义单双引号，堵住属性值注入漏洞 -
ENT_HTML5兼容 HTML5 实体（比如'），避免解析歧义 -
'UTF-8'显式声明编码，防止多字节截断绕过（尤其在旧版 PHP 或非 UTF-8 数据库连接时）
JS 上下文里 htmlspecialchars() 完全无效
当用户数据插入 JavaScript 字符串（如 var msg = "<?php echo $user; ?>";），浏览器按 JS 语法解析，不是 HTML。此时 htmlspecialchars() 不处理反斜杠、Unicode 转义或 JS 特有字符，攻击者仍可构造 "\u0022;alert(1)// 触发执行。
正确做法是：json_encode($user, JSON_UNESCAPED_UNICODE | JSON_HEX_TAG | JSON_HEX_AMP | JSON_HEX_APOS | JSON_HEX_QUOT)，并确保外层用双引号包裹（var msg = <?php echo json_encode($user, ...); ?>;）。别用 addslashes() 或手写 str_replace() —— JS 解析器不吃这套。
立即学习“PHP免费学习笔记（深入）”；
富文本不能靠 htmlspecialchars() 或 strip_tags()
论坛、商品描述等需要保留 <p></p>、<img src alt="PHP安全编程怎样防御XSS跨站脚本攻击" > 的场景，htmlspecialchars() 会把所有标签干掉，strip_tags() 则完全拦不住 <img onerror="alert(1)" alt="PHP安全编程怎样防御XSS跨站脚本攻击" >、注释混淆（<!--<script>-->）或大小写变形（<script></script>）。
必须用白名单过滤器，推荐 HTMLPurifier（Composer 安装）：
- 它按 W3C 规范解析 HTML，不是正则匹配，能处理嵌套、编码混淆、命名空间等复杂情况
- 配置示例：只允许
<p></p>、<strong></strong>、<a href></a>（且href必须以http://或https://开头） - CKEditor、TinyMCE 等前端编辑器的输出，后端仍需独立过滤——前端配置可被绕过
CSP 和 HTTP 头是纵深防御，不是替代方案
Content-Security-Policy 和 X-Content-Type-Options: nosniff 是兜底手段，不能代替输出转义：
-
Content-Security-Policy: script-src 'self'可阻止外链脚本加载，但对内联<script>alert(1)</script>或事件属性（onerror）无效，前提是输出已漏转义 -
X-Content-Type-Options: nosniff防止 MIME 类型混淆（比如把恶意 JS 响应伪装成text/plain），但它不解决 HTML 内容本身被注入的问题 - 这些 Header 在开发者某处漏了转义时能拦住一部分利用，但绝不能当成“加了就放心”的银弹
最易被忽略的点：XSS 触发在输出，不在输入。哪怕你对 $_POST 做了严格验证、用了预处理语句查数据库，只要最后 echo 时没按上下文转义，漏洞就存在。每个 echo、print、模板变量插值，都得单独判断上下文——HTML、JS、CSS、属性、URL 参数，每种都要对应不同转义方式。
