未授权测试接口常硬编码在前端js中，需通过开发者工具搜索关键词、检查隐藏元素及混淆路径，并验证响应内容与权限边界。
直接看 script 标签里的 fetch 或 XMLHttpRequest 调用
未授权测试接口往往不是藏在显眼的按钮里，而是写死在前端 JS 中——比如开发人员为了联调方便，把后台管理、数据导出、调试开关等接口硬编码进 script 标签或外部 JS 文件里。这些请求一旦没做鉴权校验，就等于把后门钥匙挂在了门口。
打开浏览器开发者工具 → “Sources” 或 “Debugger” 标签页，全局搜索以下关键词：fetch(、axios.、$.ajax、new XMLHttpRequest、/api/test、/debug、/admin、/dev。特别注意那些 URL 是拼接字符串（如 "/api/" + env + "/user"）的调用，容易漏掉动态路径。
- 重点检查
fetch的headers配置：如果没带Authorization、Cookie或只传了空值/固定 token，基本可判定为未授权入口 - 留意响应处理逻辑：如果成功回调里直接
console.log(res)或渲染到 DOM，说明接口本意就是“给人看的”，而非仅供内部调用 - 避免只扫 HTML 源码：很多接口地址根本不在
html里，而是在压缩后的main.xxx.js中，必须进 JS 文件里搜
扫描注释和隐藏元素中泄露的接口路径
开发人员常把临时接口写在 HTML 注释里，或者用 display:none 包裹一个调试用的 form 或 button，以为用户看不到就安全。但这些内容全在源码里，且极易被自动化工具捕获。
按 Ctrl+U 查看原始 HTML 源码（不是 Elements 面板），然后搜索：
-
<!--.*?/api/.*?-->（正则匹配注释中的 API 路径） <div style="display:none">.*?/api/.*?</div><input type="hidden" name="debug_url" value=".*?">-
data-api-endpoint=、data-debug-url=等自定义属性
注意：有些路径会用 base64 编码或简单异或混淆（比如 "YWRtaW4vYXBpL3Rlc3Q=" 解出来是 admin/api/test），遇到可疑字符串先 atob() 试一下。
用 SeeMore 插件快速高亮所有隐藏但可交互的元素
手动翻 DOM 效率低还易漏，SeeMore 这类插件能自动识别所有 CSS 隐藏（display:none、visibility:hidden、opacity:0）但保留 onclick、href、type="button" 等交互属性的元素——这类元素背后极大概率连着未清理的测试接口。
- 安装后点击插件图标，页面上所有“假隐藏真可用”的按钮、链接、表单都会被黄色边框高亮
- 右键高亮元素 → “检查” → 在 Elements 面板中直接定位到对应 DOM，查看其
onclick属性或父级form的action值 - 特别关注带
test、debug、mock、internal字样的 class 或 id，比如class="btn-debug-export"
它不依赖网络请求，只分析已加载的 DOM，所以即使接口已下线、JS 报错，只要 HTML 里还留着这个按钮，路径就还在。
验证时别只看状态码，重点观察响应内容与权限边界
发现一个疑似接口后，不要只发个 GET 看是不是返回 200。未授权漏洞的核心在于“不该看到的数据被看到了”或“不该执行的操作被执行了”。
- 用 Burp Suite 或 curl 直接请求，去掉所有 Cookie 和 Authorization 头，观察响应体：是否返回了用户列表、订单详情、数据库结构？
- 尝试 POST 空数据、
{"id":1}、{"action":"reset"}等常见参数，看是否触发敏感操作 - 对比登录态和未登录态的响应差异：如果两者返回完全一致，尤其是包含管理员字段（如
"is_admin": true），基本坐实漏洞 - 注意 HTTP 方法滥用：有些接口只校验 GET，但对 POST 不设防；或者用
OPTIONS请求就能绕过前置鉴权中间件
最危险的情况是：接口本身没报错、没跳转、没重定向，只是安静地返回了一堆本该 403 的数据——这种“静默泄露”最容易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
