E5.18.4nav hiding is not authorization设计
权限判断应在服务端校验，导航隐藏不能替代授权
别名: 导航不是授权 · security through obscurity · 服务端鉴权
概念解释
把一个入口从导航里拿掉，只改变了界面上好不好找，没有改变服务器接不接受那次操作。导航隐藏不是授权（nav hiding is not authorization）：谁能读、谁能写，必须在服务端对每个请求再判一次。导航策略（藏或灰）是给合法用户看的地图；授权是对所有到达该能力的路径负责，包括书签、搜索、命令面板、旧链接和直接调用。
机制
界面是众多通道里最显眼的一条。同一能力通常还挂着对象地址、通知链接、协作分享、导出接口。只在画导航时滤掉项，等于只关了大门上的灯，侧门还开着。任何只信前端的判断都会被另一条通道绕开：客户端被改掉、旧会话里缓存了入口、自动化脚本不走界面。服务端若因为「导航里没有这项」就假设不会接到请求，就会在这些通道上用错身份执行。
隐藏与授权的职责分层一旦混在一起，修界面的人会以为「已经藏了所以安全」，修接口的人会以为「界面会挡着所以接口可以松」。两边都松时，能力对不该用的人仍然可达。正确分层是：导航按权限画地图，每一个读或写的请求自己带身份、自己过授权，失败返回与权限相关的拒绝，而不是靠「找不到按钮」来保护数据。
边界
纯展示、没有背后请求的文案（营销模块名）谈不上授权，藏不藏只影响认知。公开资源本来就允许任何人读，导航藏不藏与授权无关。客户端可以先按权限画界面，减少注定失败的点击，这是体验优化，不能当成最后一道关。调试或管理员「以用户身份查看」必须仍以该用户的授权为准去打服务端，而不是只把导航画成那副样子。
怎么落地
- 每个会读取或改写受保护对象的请求在服务端按当前身份授权；界面藏不藏、灰不灰不作为放行依据。
- 深链、搜索、通知、命令面板与导航遵守同一授权结果，不要出现「按钮没有但链接能进」。
- 拒绝时返回权限不足，不要伪装成「资源不存在」，除非泄露存在性本身不可接受。
- 验证：在无权账号下不走导航，用已知地址或搜索打开该能力，应被拒绝。开通后再走同一地址应成功。界面隐藏而直达成功，就是把授权误放在了导航上。核对服务端日志里是否每次都有授权判断，而不是只在画菜单时判断一次。