接口按钮隐藏了，为什么用户还能越权操作？后端权限校验这样补齐

很多后台系统都会按角色隐藏按钮：普通运营看不到“删除订单”，客服看不到“退款审批”，实习账号看不到“导出全部”。界面上看起来安全了，但只要接口没有做后端权限校验，用户仍然可以从浏览器网络面板、脚本或接口工具里直接发请求。

这就是常见的越权操作问题。前端按钮隐藏只能减少误点，不能作为安全边界。真正的控制点必须放在服务端：每一次敏感接口请求，都要重新确认当前用户是谁、属于哪些角色、能不能操作这条数据，以及这次拒绝或放行是否留下审计记录。

生产目标：按钮隐藏不是权限边界

先明确目标：前端负责“展示当前用户应该看到什么”，后端负责“决定当前请求能不能落库”。这两个职责不能混用。

一个典型风险场景是：

• 页面根据角色隐藏了“删除订单”按钮。
• 用户从历史请求、接口文档或浏览器网络面板里拿到了删除接口地址。
• 后端只校验登录态，没有校验 order:delete 权限。
• 请求直接进入业务层，订单状态被改掉。

这类问题不是“前端没藏好”，而是接口入口缺少权限门禁。生产目标应该写成可验证的规则：

每个敏感接口必须同时满足：
1. 用户已登录
2. 用户具备资源动作权限
3. 用户具备目标数据范围
4. 拒绝和放行都有审计记录

环境准备：先整理用户、角色和资源动作

加固之前，不建议直接在每个控制器里临时写判断。先把权限模型整理清楚，至少包含三张关系：

• 用户和角色：一个用户可以有多个角色，例如 客服、运营、管理员。
• 角色和动作：角色能做哪些资源动作，例如 order:view、order:refund。
• 用户和数据范围：用户能操作哪些门店、部门、租户或项目。

可以用一份权限矩阵先落地：

矩阵不是最终代码，但它能把“这个按钮谁能点”转成“这个接口需要哪个动作权限”。后续前后端都围绕同一套动作名实现，避免界面和接口各写一套规则。

安全配置：在接口入口统一做权限判断

后端应该在路由、中间件或统一拦截层做权限判断，而不是依赖业务函数里零散的 if。下面是一个接近伪代码的示例，重点是结构，不绑定具体语言框架：

$routes = [
    'POST /api/orders/delete' => [
        'handler' => 'OrderController@delete',
        'permission' => 'order:delete',
    ],
    'POST /api/orders/refund' => [
        'handler' => 'OrderController@refund',
        'permission' => 'order:refund',
    ],
];

function guardRequest(array $user, array $route, array $body): array
{
    if (!$user) {
        return deny('NOT_LOGIN');
    }

    if (!hasAction($user, $route['permission'])) {
        return deny('NO_ACTION_PERMISSION');
    }

    if (!inDataScope($user, $body['order_id'] ?? 0)) {
        return deny('OUT_OF_SCOPE');
    }

    return allow();
}

这样做有三个好处：

• 每个接口需要什么权限，一眼能从路由配置看到。
• 权限失败时可以统一返回错误码，前端也更容易处理。
• 审计日志可以在同一个入口记录，不会漏掉某个控制器。

权限边界：不仅看角色，还要看数据范围

只看角色还不够。常见越权分两类：功能越权和数据越权。

• 功能越权：客服没有退款审批权限，却调用了退款接口。
• 数据越权：A 门店员工有查看订单权限，但查看了 B 门店订单。

所以校验不能只写成“是否有 order:view”。更稳的规则是：

动作权限：能不能调用这个接口
数据范围：能不能操作这条记录
状态约束：这条记录当前能不能被操作

例如退款接口至少要检查三件事：

function canRefund(array $user, array $order): bool
{
    if (!hasAction($user, 'order:refund')) {
        return false;
    }

    if (!belongsToUserScope($user, $order['store_id'])) {
        return false;
    }

    return $order['status'] === 'PAID';
}

注意状态约束也属于安全边界。用户有退款权限，不代表可以退款已关闭、已过期或已完成风控拦截的订单。

日志审计：拒绝和放行都要能追踪

权限系统上线后，日志不是可选项。没有日志，就很难回答“谁在什么时候尝试操作了哪条数据”。建议审计日志至少记录：

• 用户 ID、角色、客户端 IP。
• 接口路径、动作权限、目标资源 ID。
• 校验结果：放行、未登录、无动作权限、超出数据范围、状态不允许。
• 请求追踪 ID，方便和网关日志、业务日志串起来。

{
  "trace_id": "req-20260630-001",
  "user_id": 318,
  "action": "order:refund",
  "resource": "order:90021",
  "result": "NO_ACTION_PERMISSION",
  "ip": "10.1.8.21"
}

拒绝日志尤其有价值。它能帮助发现有人在绕过页面直接请求接口，也能帮助定位前端按钮规则和后端权限配置不一致的问题。

发布检查：用三类账号做回归验证

发布前不要只用管理员账号测试。至少准备三类账号：

• 无权限账号：按钮不可见，直接调接口应返回权限错误。
• 有功能权限但无数据范围账号：能看到入口，但操作其他门店数据应被拒绝。
• 完整权限账号：页面可操作，接口可放行，审计日志完整。

回归清单可以这样写：

页面层：按钮显示与权限矩阵一致
接口层：直接请求敏感接口仍会校验
数据层：跨门店、跨租户数据被拒绝
日志层：放行和拒绝都有审计记录
告警层：短时间内大量拒绝请求会触发提醒

最后总结：按钮隐藏不是安全边界，后端权限校验才是。把接口动作、数据范围、状态约束和审计日志串成一条固定调用链，才能真正补齐越权操作风险。上线时用不同权限账号做回归，才能确认这套规则不是只在管理员视角下“看起来正常”。