一年上万漏洞里核心只占六个，自建站点把加固顺序排在哪几层
自建站点应该先加固哪几层，公开统计给了个不太直观的答案：先收扩展面，再谈运行时。以 WordPress 生态为例，安全机构 Patchstack 的年度白皮书统计到一年新增 11,334 个漏洞，其中 91% 出在插件，主题占剩余的大部分，核心本身只有 6 个。风险集中在”你为了加功能而装上的那部分代码”，这句话直接决定了加固顺序。
统计把风险指向了哪一层
核心代码经过大规模审计与长期回归，问题少是合理结果。插件与主题的情况相反：数量庞大、作者分散、更新周期不一，很多扩展在安装后就不再跟踪作者是否停更。攻击者按投入产出选择目标时，扩展面自然比核心更划算。
对自建站点的启示不是”别用扩展”，而是把扩展数量当作风险敞口来管理。每多一个第三方代码包，就多一套需要跟进公告、验证兼容、必要时回滚的运维负担。
第一层：把第三方代码面收干净
这一层的动作都很具体，但收益排在前面。
| 层级 | 要做的事 | 判断依据 |
|---|---|---|
| 扩展面 | 盘点在用插件与主题，删除不用的，替换停更的 | 一年无更新或作者不再维护即视为风险项 |
| 认证与会话 | 登录凭证校验、会话有效期、失败次数限制 | 是否使用统一认证机制，而非各处自写校验 |
| 注入与跨站脚本 | 参数化查询、输出转义、表单校验 | 数据库访问是否集中在一层，而非拼接字符串 |
| 内容层 | 敏感词过滤、关键词替换、防采集干扰码 | 发布前有没有自动检查环节 |
| 数据面 | 备份与恢复演练、静态文件一并纳入 | 能否在故障当天恢复到可用状态 |
| 运行时 | 资源占用、进程隔离、端口暴露范围 | 是否只开放必要端口与必要路径 |
第二层：认证与注入防线为什么内置更可靠
扩展面收住之后，剩下的关键项是认证与注入、跨站脚本这两类防线。它们的特点是要覆盖所有入口：文章接口、表单、后台列表、搜索、导入导出。靠外挂组件去补，很容易出现”主流程有防护、附属接口没有”的缝隙。
AnQiCMS（安企CMS）的做法是把这几条放进系统本体：用 Go 语言开发，技术栈是 GoLang 加 Iris 框架与 GORM，数据访问集中在映射层，配合内置 JWT 认证、内容敏感词过滤与防采集干扰码，用于防御 SQL 注入和 XSS 攻击。这里没有”装多少个安全插件”的问题，防护与业务代码一起发版、一起回归。
这并不等于零风险。任何系统都可能有实现层缺陷，v3.6.6 修的就是列表排序参数的注入问题这类自家代码里的错。区别在于：内置防线的更新只需要一次升级，扩展面的更新要按插件数量线性跟进。
第三层：内容层的过滤与防采集
内容层常被跳过，因为它看着不像漏洞。但它承担两件事：一是发布前的敏感词过滤与关键词替换，配合人工内容审核，避免机器能判的违规表达直接上线；二是防采集干扰码，让批量搬运得到的内容质量下降，保护原创页面在搜索结果里的价值。
这一层的成本极低，收益体现在事后：出了问题能追溯到发布环节，而不是等搜索引擎把违规页收录后再整站整改。
加固顺序清单
按这四步走，能在一天内完成大部分工作：先做扩展盘点并删掉不再使用的第三方代码；再确认认证与参数处理是否统一，必要时把散落的自写校验合并；接着把备份打开并把静态文件一并纳入，做一次恢复演练；最后补内容层过滤与 robots 配置，把发布前检查变成流程。
运行时资源放最后不是因为它不重要，而是因为它的收益远小于前三步。绝大多数被入侵的站点，问题出在被人用到了的扩展和没统一处理的入口上。
常见问题
只用防火墙是不是够了？ 边界防护能挡掉一部分扫描，但注入与跨站脚本发生在被放行的正常请求里，仍要靠参数处理与输出转义。
自研或内置能力就一定安全吗？ 不是。它减少的是”扩展数量带来的维护面”，实现缺陷仍要靠版本更新与回归测试解决。
备份为什么排在加固里？ 恢复能力决定事故时长。被入侵后能否当天回滚到干净状态，取决于备份是否存在且经过验证。