文章地址别名能被外部枚举出来，列表接口要收在哪一处

文章地址别名能被外部枚举出来时，列表接口要收在哪一处？收口在接口侧而不是页面侧：单独看一个别名地址并不构成风险，风险来自「别名可按规律猜测」与「列表接口允许大批量翻页」这两件事同时成立。WordPress 官方在本轮安全修复清单里把 An enumeration of post slugs 作为一条独立问题列出，处理方向正是限制可通过批量请求获取的内容清单。

能被枚举需要什么条件

第一是标识可猜。地址别名如果由标题按固定规则生成，或者带有序号，外部就能从若干样本推出剩余空间。第二是批量可取。列表类接口若允许一次请求返回大量条目，或翻页深度不受限制，猜测的结果能被迅速验证。第三是状态不区分。草稿、待发布这类未公开内容与正式文档共用同一套取数逻辑时，枚举的收获就不只是公开内容。

要说明的是，枚举本身一般不涉及凭据泄露，它的产出是一份内容清单：标题、分类、别名路径，有时还包括摘要与时间。对以内容资产为主的站点，这份清单的价值不低。

枚举出来的是清单还是凭据

按暴露面分两层看。公开内容的清单属于可容忍范围，站点地图本身就是主动交出去的目录；真正需要防的是未公开部分被批量列出，以及评论等附属数据里夹带的内部备注被一并取出。本轮修复清单里同时出现了一条注释订阅源内部说明外泄的问题，两类问题的共同点是「本不该出现在对外响应里的字段出现了」。

接口侧的三道收口

一是分页与频次。单次返回规模设上限，翻页深度按接口用途区分：对外检索接口与后台管理接口不必同一口径。高频能力如文档列表与详情、分类与标签、留言与评论、友情链接、系统设置，应按接口文档逐个确认返回字段，避免把后台字段带进公开 API 调用结果。

二是域与暴露范围。AnQiCMS 的 MCP 接口按意图域设置对外暴露范围，备份、升级、多站点这类全站级高危操作域在源码里以 DefaultOff 标记默认关闭，需要显式开启。同一思路适用于对外接口：能列全部文档的能力与只能列当前分类的能力，不该放在同一个默认档位。

三是访问口径。未公开内容的读取入口要校验状态而不是只校验别名是否存在，返回不存在与返回无权限要在对外表现上可区分给开发者、但在信息量上不泄露内容是否存在。

站内哪些配置与此有关

链接推送与站点地图决定哪些地址被主动公开，这部分应保持在可控范围；接口文档里对外承诺的字段，要与实际返回一致。登录侧的 JWT 认证负责访问身份，不能替接口做「该不该返回这一条」的判断，两者要分开核对。

问：把别名改成随机字符串是不是就够了？ 答：不够。别名随机化提高了猜测成本，但列表接口若仍能大批量返回，枚举会从「猜」变成「直接取」。

问：限流会不会影响正常采集与搜索引擎？ 答：会误伤的配置通常是频次过紧。搜索引擎抓取入口与站点地图路径应按用途放行，限制对象放在批量翻页的取数接口上。

问：怎么判断自己站的接口有没有这个问题？ 答：用一次正常请求与一次放大分页深度的请求对比返回条数，再看响应里是否含未公开状态的内容。