待审核的评论里能藏住存储型XSS吗，后台页面的注入点怎么收敛

能。待审核评论没有对外展示，但它会被后台列表页读取并渲染出来——管理员打开审核队列的那一刻，这段内容就已经进入了页面。存储型 XSS 的关键从来不是「内容是否公开」，而是「内容是否在某处被当作代码解释」。WordPress 在 7.1.3 安全版本中修复的其中一项，就是评论管理后台页面的存储型 XSS，明确可通过待审核评论触发。

为什么没发布的内容也能触发

一个常见的误解是把前台当成仅有的渲染场景。实际的渲染面至少有三处：前台文章页与评论区、后台的评论列表与文章编辑页、以及通知或摘要类页面。后台列表页往往把提交者昵称、邮箱、评论内容做不同程度的展示，只要有一处把存储的原文拼接进 HTML，未审核的恶意片段就会在那里执行。

第二处误解是把「不显示完整内容」当成安全。列表页哪怕只截取前几十个字符，截断位置之前的脚本片段依然可能被浏览器解释执行。

注入点的三类常见位置

第一类是提交字段直接进入 HTML：昵称、网址、评论正文，这三项通常允许较长文本且少被校验。第二类是结构化字段被当作属性或样式值使用：图片地址、颜色值、URL 参数，绕过点常出现在特殊字符处理与协议前缀判断上。第三类是导出与二次处理路径：把内容写入报表、导出文件或统计页面时做了另一套拼接逻辑，前台安全而后台出问题多属于这一类。

AnQiCMS 在 README 事实口径里把 XSS 与 SQL 注入的防御归到内置机制上：JWT 认证负责会话，内容敏感词过滤负责入库侧治理，防采集干扰码负责内容保护。这三项都不等于输出转义，转义必须在渲染层完成。

入库过滤与渲染转义分工

两者职责不同，不能互相替代。AnQiCMS 的内容安全设置提供敏感词过滤与关键词替换、内容审核，这属于入库侧治理，处理的是「内容该不该留、要不要替换」。防注入靠的是渲染阶段按上下文转义：出现在 HTML 文本位置做实体转义，出现在属性位置做引号包裹，出现在链接协议位置做白名单校验。

只看入库过滤会出现两个典型失败：过滤规则按关键词命中，绕过大写、编码与空白变体；替换后的内容仍然带着可执行结构，只是换了写法。反过来，只做输出转义也无法处理合规与质量诉求，两层要同时存在。

审核链路上的分级权限

待审核内容本身是敏感数据。WordPress 同一份公告里还有另一项修复：私有与未发布文章的评论存在未授权可见问题。这说明风险不只是脚本执行，还包括越权读取。

收敛顺序建议这样排：先确认哪些角色能读取未发布内容的评论，把范围收到必要最小；再确认审核动作是否需要独立权限，不要让「看到」等同于「放行」；然后把会话与令牌侧收紧，AnQiCMS 内置 JWT 认证，令牌有效期与轮换要纳入后台账号管理；最后用表单侧的 reCAPTCHA 验证码把机器提交量压下来——审核队列里的恶意样本数量下降，人工误点的概率随之下降。

常见问题

关掉评论功能是不是就安全了？ 消除了这一类入口，但留言、注册、投稿表单属于同一形态，任何允许外部文本入库再回显的路径都要按同样标准检查。

打了补丁要不要清理历史数据？ 要。存储型问题的恶意片段留在库里，转义修复只改变渲染结果，历史数据仍会带着可疑结构出现在导出与统计里。

验证码能替代审核吗？ 不能。验证码挡的是自动化提交这一段的量，内容风险要靠入库过滤与审核放行。

怎么验证自己站点的后台是否受影响？ 用一条不含脚本的标记文本提交评论，不进后台，只看后台列表页对尖括号与引号的显示结果，能判断转义是否在渲染层发生。