PHP存储型XSS的核心是输出时未按上下文编码：HTML正文用htmlspecialchars，JS字符串用json_encode，URL参数用urlencode，并需CSP、HttpOnly等纵深防御。
PHP 存储型 XSS 的核心问题不是“能不能存”，而是“存进去之后怎么安全地展示出来”。它不像反射型那样只影响点击链接的人，而是把恶意脚本埋进数据库，所有访问该页面的用户都会中招——评论、昵称、文章内容、个人简介等任何用户可编辑又会被前端渲染的字段，都可能是入口。
输入环节：别迷信“过滤”就能一劳永逸
很多开发者第一反应是“在入库前把 <script>、onerror 这类关键词全删掉”。但这种黑名单式过滤极易被绕过，比如用大小写混写、加空格、用 HTML 实体编码、或改用 svg/onload 等冷门标签。更危险的是，过度过滤可能破坏正常业务，比如用户想发一条带代码块的编程笔记。</script>
真正稳妥的做法是：
- 非富文本场景（如昵称、标题）：严格白名单校验，只允许字母、数字、常见符号，拒绝一切 HTML 标签和事件属性
- 富文本场景（如论坛正文、编辑器内容）：必须使用专业净化库，如 HTMLPurifier 或 Parsedown + 自定义规则，而不是自己写正则
- 入库时不做转义处理（如 htmlspecialchars），因为转义是输出阶段的事；存储原始数据，保持语义完整
输出环节：按上下文精准编码，一步都不能错
漏洞往往爆发在读取数据库后直接 echo 到 HTML 页面的那一行。哪怕输入再干净，只要输出没编码，照样执行脚本。
立即学习“PHP免费学习笔记（深入）”；
关键原则是：**数据插到哪，就用对应上下文的编码方式**：
- 插入 HTML 正文（如 <div>xxx</div>）：用 htmlspecialchars($data, ENT_QUOTES, 'UTF-8')
- 插入 HTML 属性（如 <input value="xxx">）：同样用 htmlspecialchars，且确保属性值用引号包裹
- 插入 JavaScript 字符串（如 var msg = "xxx";）：必须用 json_encode($data, JSON_UNESCAPED_UNICODE)，不能用 htmlspecialchars
- 插入 URL 参数（如 href="page.php?x=xxx"）：用 urlencode()，不是 htmlspecialchars
防御加固：不止于编码，还得有纵深
单靠输出编码能解决 90% 的问题，但面对高级绕过或浏览器解析差异，还需叠加防护：
- 设置 Cookie 的 HttpOnly 属性，让 document.cookie 无法被 JS 读取，大幅降低会话劫持风险
- 配置 Content-Security-Policy 响应头，例如 Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'，禁止加载外部脚本、禁用内联脚本（去掉 'unsafe-inline' 更安全）
- 在模板引擎层面启用默认转义（如 Twig、Blade、Smarty 默认开启 autoescape），避免开发者手动漏掉
- 对高敏感操作（如修改密码、转账）强制二次验证，不依赖前端 JS 控制权限
