文章总结： Web权限漏洞难以根治的本质是架构债务而非人为疏忽。若系统存在接口默认可访问、校验逻辑分散及权限模型失控三个结构性缺陷，漏洞必周期性复发。建议停止救火式修补，转向架构重构：实施默认拒绝策略、建立统一强制校验框架、规范权限定义与映射，从而构建可靠的系统安全机制。
综合评分： 89
文章分类： WEB安全,安全建设,漏洞分析
Web 权限漏洞，为什么永远修不干净？
数据安全合规交流部落
2025年12月24日 08:28
广东
以下文章来源于架构安全观
，作者六哥
架构安全观
.
专注于Web系统安全性的深度剖析。从稳固的架构设计出发，复盘真实的攻击路径，探讨如何通过持续的安全运营构建动态防御体系。
从事 Web 开发或安全相关工作的人员，极有可能遭遇过以下令人困扰的情形：被通报的是一个较为简单的越权漏洞，攻击者借助普通用户权限获取了管理员权限；随后紧急进行修复、上线，并开展复盘工作，同时向开发人员着重强调“接口必须添加权限校验”；然而，三个月后，另一个新接口又因遗漏权限校验，被检测出同样的权限问题。
许多团队将此类问题归咎于“开发人员粗心大意”，于是采取了诸如增加检查清单、提出安全测试用例、开展代码扫描等措施。但权限漏洞依旧层出不穷，如同割韭菜一般，一茬接着一茬。
实际上，在绝大多数情况下，这并非是“人员不够认真”所导致的问题，而是系统从根本上就存在“结构性缺陷”。只要满足三个特定条件，权限漏洞就必然会周期性地反复出现。
如果一个 Web 系统同时满足下面 3 个条件，建议技术、安全负责人立即启动权限架构重构评估，而非继续投入人力“救火式修漏洞”。
1️⃣ 新增接口在未进行显式权限声明的情况下，默认具备可访问性
2️⃣ 权限校验逻辑分散在业务代码中，而不是一条强制路径
3️⃣ 没有人能说清楚：系统里一共有多少种权限
只要系统持续迭代，权限漏洞必然周期性复发，其本质是“架构债务”而非“执行问题”，管理者需优先考虑“治根”而非“治标”。
一、为什么“修不干净”，从来不是能力问题？
先给大家看一个几乎所有中大型团队都踩过的“权限漏洞循环”：
- 渗透测试、用户反馈、黑产攻击，发现一个越权漏洞（比如普通用户能查他人订单、低权限账号能改配置）；
2.开发紧急定位接口，在业务代码里加一行权限校验，如下：
if (user.getId() != order.getUserId()) return 403;
-
测试回归验证，漏洞修复；团队开会强调“以后写接口必须加权限，不许再犯”;
-
1至6个月后，新功能上线，又出现新的权限漏洞，循环重演。
表面上看，每一次循环的原因都很明确：要么是开发写接口时忘了加校验，要么是测试没覆盖到边缘场景，要么是安全评估漏了这个接口。但实际上核心问题只有一个，也是管理者需重点审视的：系统是否具备“阻止权限错误自然发生”的能力？这直接决定了权限漏洞的治理成本和风险可控性。如果系统本身没有阻止权限漏洞产生的底层机制，那么任何一次修复都只是“治标”，不仅会重复投入人力（开发+测试+安全复盘），漏洞还会反复出现。
二、判断标准一：新增接口默认可访问，把安全交给“记性”
只要一个系统允许“不写权限代码”的接口上线，那么权限漏洞就不可能被根治。
这是一个“默认策略”问题，和技术选型（Spring Security、Shiro）、开发语言（Java、Go、Python）都没关系，可以先看两个完全不同的接口开发流程：
反例：
1.产品提需求：开发一个“查询用户订单列表”的接口；
2.开发写业务逻辑：查数据库、封装返回值，接口能正常调用就完事；
3.测试只测“正常用户能查到自己的订单”，没测“普通用户能不能查别人的订单”；
4.接口上线，几天后被测出越权漏洞。
正例：
1.产品提需求：开发一个“查询用户订单列表”的接口；
2.开发写业务逻辑后，发现没配置权限，接口直接返回403；
3.开发在统一权限配置中心，声明该接口需要“ORDER_QUERY”权限，且只能查询当前登录用户的订单；
4.测试不仅测正常场景，还测“无权限用户访问”“有权限用户查他人数据”，均被拦截；
5.接口上线，无权限漏洞。
两者的核心区别的是：权限校验是“默认开启”还是“默认关闭”?
很多系统的逻辑是“不写权限代码=默认可访问”，这就意味着，每一次功能迭代，都是在赌“开发有没有记得写权限校验”“测试有没有覆盖到权限场景”。当系统有10个接口时，漏写的概率不高；当系统有上千个甚至上万个接口、每月新增大量接口时，漏写就是必然。这种“默认开放”的策略会形成路径依赖：开发习惯“写完业务再补权限”，“权限校验”从“必须做的事”变成了“可选项”。对管理者而言，这意味着“权限安全”完全依赖团队自觉性，既无法量化风险，也无法通过流程管控，最终必然陷入“漏洞-修复-再漏洞”的恶性循环。
三、判断标准二：权限校验分散在业务代码中—没有“强制路径”的约束都是空谈
当权限校验可以被复制、被改写、被遗漏，这将不再是“约束”，而是“习惯”。
查看代码库，搜索一下权限校验相关代码，大概率会发现至少三种以上的写法共存。以Java项目为例：
// 写法1：直接在业务代码里写校验逻辑@RequestMapping("/order/detail")public Result orderDetail(Long orderId, HttpServletRequest request) { User user = getUser(request); Order order = orderMapper.selectById(orderId); // 权限校验 if (!order.getUserId().equals(user.getId())) { return Result.error(403, "无权限"); } return Result.success(order);}// 写法2：用注解做角色校验@RequestMapping("/user/list")@PreAuthorize("hasRole('ADMIN')") // 只有管理员能访问public Result userList() { List<User> userList = userMapper.selectList(null); return Result.success(userList);}// 写法3：调用权限服务校验@RequestMapping("/config/update")public Result updateConfig(Config config) { User user = getUser(request); // 调用权限服务 boolean hasPermission = permissionService.check(user.getId(), "CONFIG_UPDATE"); if (!hasPermission) { return Result.error(403, "无权限"); } configMapper.updateById(config); return Result.success();}// 写法4：忘了写校验（新增接口时漏了）@RequestMapping("/log/query")public Result queryLog(String startTime, String endTime) { List<Log> logList = logMapper.queryByTime(startTime, endTime); return Result.success(logList);}
你可能会说：“多种写法没关系，只要都能实现校验就行。”但实际开发中，这会带来三个严重问题：
1.校验逻辑不统一，容易出现逻辑漏洞：比如写法1里，若开发误写成“==”，就变成了“只有别人能访问”；写法2里，若注解加在实现类而不是接口上，可能被动态代理绕过；写法3里，若权限服务返回“false”时开发漏写判断，就等于没校验。
2.校验可被跳过，无法形成强制约束：对于内部调用的接口（比如服务间调用、定时任务调用），很多开发会觉得“调用方是可信的”，直接跳过权限校验。但随着系统迭代，内部调用路径越来越复杂，一旦有一个环节的权限校验被跳过，就可能形成权限绕过。
3.排查和维护成本极高：当出现一个权限漏洞时，你需要逐个接口排查：它用的是哪种校验方式？校验逻辑有没有问题？有没有被跳过的情况？而不是直接定位到统一的权限校验模块。
真正的权限约束，必须是“绕不开的”，不管是对外接口还是内部接口，不管是普通用户还是管理员，都必须经过同一条权限校验路径。对技术、安全负责人而言，这意味着需要搭建统一的权限框架（如网关层拦截），将权限校验从“业务开发的可选动作”变为“系统层面的强制动作”，降低执行成本，也为后续审计提供支撑。
四、判断标准三：没人能回答“系统一共有多少权限”—失控的权限模型等于没有模型
一个无法枚举自身权限的系统，等价于“没有权限模型”。
这是一个极其简单，但90%以上的中大型系统都答不上来的问题：“我们系统现在一共有多少种权限？分别对应哪些接口？哪些角色拥有这些权限？”
太多团队的真实情况：
-
问开发负责人，他说“大概有几十种吧，具体得翻代码”；
-
问测试负责人，他说“测试用例里有一部分，还有一些是老接口的权限，可能没记录”；
-
问安全负责人，他说“我们只关注高危权限，低危权限没统计过”；
-
最后翻代码、翻配置、翻数据库，花了大量时间，统计出一个“大概的数量”，还不能保证没遗漏。
这不是管理问题，也不是文档问题，而是权限规则已经无法被系统自身理解、审计和约束，对安全管理人员而言，这意味着无法完成“权限最小化”核查、无法及时发现“僵尸权限”“过度授权”等隐性风险；对开发人员而言，这是典型的“架构债务”，后续重构的成本会随系统规模指数级增长。
权限模型失控的背后，是两个核心问题：
1.权限定义不规范：有的权限是按“功能”定义（比如“查询订单”“修改订单”），有的是按“数据”定义（比如“查看自己的订单”“查看所有订单”），有的是按“角色”定义（比如“管理员权限”“普通用户权限”），混乱的定义导致无法统一枚举。
2.权限和接口没有绑定关系：很多系统的权限是“游离”的，一个接口可能对应多个权限，一个权限可能对应多个接口，没有统一的映射关系。当接口迭代时，权限映射关系没有同步更新，久而久之，就形成了“僵尸权限”（权限存在但没人用）和“隐形权限”（接口需要权限但没记录）。
更危险的是，当权限模型失控后，根本不知道“哪些权限是高危的”“哪些权限被过度分配了”。比如一个普通运营账号，可能因为历史迭代中的权限遗漏，被分配了“修改系统配置”的高危权限，而你直到出现安全通报或者安全事件才会发现。
五、真实世界验证：为什么成熟项目也会反复中招？
可能有人会说：“我们系统是成熟项目，有专门的安全团队，应该不会有这种问题？”但事实是，像Jenkins、GitLab这些顶级开源项目，每年都会曝出多次权限相关漏洞。
就拿Jenkins来说，2023年就爆出CVE-2023-28640权限漏洞，核心是“权限校验被绕过”。这些项目难道缺乏安全意识？难道没有经验丰富的开发者？显然不是。
它们反复中招的一个核心共同点是：权限校验依赖“调用者是可信的”这一假设。
比如Jenkins的很多内部接口，最初是为“管理员操作”或“插件调用”设计的，开发者默认“只有可信的调用者会访问这些接口”，所以没加严格的权限校验。但随着Jenkins生态扩展，插件数量越来越多，调用路径越来越复杂，有的新增功能复用了老的内部接口，却没同步加上权限校验。
再比如GitLab，曾曝出“普通用户可通过特定API 访问其他用户私有项目”的漏洞，原因是新增API时，复用了老的查询逻辑，但漏写了“项目权限校验”，不是开发者没考虑到安全，而是系统结构允许这种“遗漏”存在。
这些案例证明：哪怕是最顶尖的团队，只要系统结构存在缺陷，权限漏洞就会“野火烧不尽，春风吹又生”。对管理者而言，关键启示是：不要将“权限安全”寄托于“团队经验”或“安全意识”，而要构建“不依赖人的安全架构”；成熟项目反复中招，本质是早期权限设计未考虑“生态扩展”和“调用链路复杂化”，这正是需要提前预判的架构风险。
六、立刻验证与自己相关的系统
如果你现在负责或维护一个 Web 系统，不用找安全团队，不用翻大量文档，花 30 分钟就能判断系统是否陷入“权限漏洞循环”。
只需要做这 3 步：
Step 1：问自己一个问题
“如果我现在新增一个接口，不写任何权限代码（包括注解、业务逻辑、权限服务调用），部署上线后，外部用户能访问这个接口吗？”
-
如果答案是“能访问”“不确定”“要看部署环境” ，命中标准一；
-
如果答案是“不能访问，会直接返回403” ，未命中标准一。
Step 2：搜一类代码
在代码库中搜索以下关键词（根据你的技术栈调整），统计权限校验的写法数量：
-
Java：@PreAuthorize、hasRole、hasPermission、权限服务类名（比如 PermissionService）；
-
Go：auth、permission、checkPermission；
-
Python：@permission\required、check\perm。
如果出现以下情况，命中标准二：
-
存在 2 种及以上不同的权限校验写法；
-
部分接口没有任何权限校验代码；
-
权限校验代码散落在控制器、服务层、工具类等多个地方。
Step 3：问负责人一句话
直接问负责人：“系统现在一共有多少种权限？分别对应哪些接口和角色？”
如果出现以下情况，命中标准三：
-
没人能立即给出明确答案；
-
不同人给出的答案不一致；
-
需要翻代码、翻配置、查数据库才能统计，且统计结果无法保证完整。
命中2条及以上，就不要再纠结“如何修某一个权限漏洞”了，哪怕你现在修复了所有已知漏洞，下一次迭代还是可能会出现新的漏洞。此时最该做的：
1.暂停“救火式修复”，组织核心团队（开发+安全+测试）开展权限架构评审；
2.量化重构投入产出比（对比“每年漏洞修复总成本”与“一次重构成本”）；
3.向上同步风险：明确告知业务方“现有架构下权限漏洞无法根治，可能引发的业务损失和合规风险”；
4.制定重构路线图，优先保障核心业务接口的权限框架迁移。
七、为什么 Checklist 和扫描器解决不了这个问题？
很多团队在发现权限漏洞反复后，会想到用“工具”来解决：比如做一个《接口权限校验 Checklist》，要求开发每写一个接口都勾选；或者引入代码扫描工具，自动检测“有没有漏写权限校验”。
但这些工具只能解决“已知问题”，解决不了“结构性问题”。Checklist的核心问题是“依赖人的执行”：开发可能因为赶工期跳过勾选，测试可能因为粗心漏看检查项；更重要的是，Checklist只能覆盖“已知的权限场景”，对于新增的业务场景（比如多租户权限、数据行级权限），Checklist 跟不上，还是会出现漏洞。
代码扫描工具的核心问题是“只能检测形式，不能检测逻辑”：它能检测到“这个接口没加@PreAuthorize注解”，但检测不到“这个注解加错了角色”“校验逻辑写反了”“内部调用跳过了校验”；它能检测到“有 permissionService.check调用”，但检测不到“check返回false时没处理”。能解决“有没有按规矩做”的问题，但解决不了“规矩本身有没有问题”的问题。
而我们面临的“权限漏洞反复”，本质是“规矩本身有问题”，系统结构允许权限漏洞自然产生。对安全管理人员而言，需清醒认知：Checklist和扫描器只能作为“辅助手段”，无法替代架构层面的安全设计；若过度依赖工具，反而会因“工具检测通过”产生虚假安全感，忽视底层风险。
八、最后
继续在有结构性缺陷的系统里修权限漏洞，本质上是在用“人力成本”抵消“系统设计缺陷”，投入的精力，都只是在填补系统本身的窟窿，而这个窟窿会随着系统迭代越来越大。对管理者而言，需重点核算三类成本：
1.直接成本：漏洞修复的开发、测试人力、安全应急响应成本；
2.间接成本：漏洞导致的业务中断、用户流失受损；
3.合规成本：因权限管控不足无法通过等保、攻防演练被攻破，或面临监管处罚。
真正的成本，从来不是某一个漏洞的修复成本，也不是漏洞被利用后的损失，而是“不确定性成本”，你永远不知道下一个漏洞会出现在哪里，永远不知道什么时候会被攻击者利用，永远要为“可能存在的漏洞”投入大量人力做复盘、做扫描、做测试。
如果你的系统已经命中了前面说的2条及以上“判断标准”，管理者需牵头推动权限重构，核心落地路径如下：
-
把“默认开放”改成“默认关闭”，所有接口必须显式声明权限才能访问；
-
搭建统一的权限校验框架，所有接口走同一条强制校验路径；
-
规范权限定义，建立“权限-接口-角色”的统一映射表，定期审计；
-
废除“内部调用无需权限”的假设，所有调用都必须经过权限校验。
这可能需要投入较长时间，可能会影响短期的功能迭代，但从长期来看，这是唯一能跳出“权限漏洞死循环”的办法。可通过“分阶段迁移”平衡迭代节奏（先覆盖核心业务，再逐步迁移非核心接口）；管理人员需全程参与重构过程，确保新框架符合“权限最小化”“可审计”“可追溯”原则，同步完善权限管理制度和审计流程。
毕竟，真正的安全，不是靠“人够认真”，而是靠“系统够可靠”。对技术、安全负责人而言，核心责任不是“解决每一个漏洞”，而是“构建让漏洞无法轻易产生的系统”，这才是对业务最根本的安全保障。
最后，欢迎技术负责人、安全管理人员在评论区交流：你的系统命中了几条“判断标准”？在推动权限架构重构时，如何平衡短期迭代与长期安全？是否有过权限漏洞引发的数据泄露经历？
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：数据安全合规交流部落 《Web 权限漏洞，为什么永远修不干净？》