防止越权访问需每次请求校验身份、资源和权限三要素，php后端须在数据库操作前动态验证，禁用客户端传入id或角色，强制归属约束与细粒度策略判断，并辅以日志审计和二次验证。
防止越权访问不是靠“拦住不该进的人”，而是让每个请求都明确回答三个问题：你是谁？你想操作哪个资源？你有没有这个权限？PHP 后端必须在每次数据库操作前完成这三重校验，不能依赖前端传来的 ID 或角色字段。
用户身份与上下文强绑定
登录后生成的 session 或 token 必须携带可验证的用户唯一标识（如 user_id）和最小必要权限范围（如所属部门、角色类型），且该信息不应由客户端传入或篡改。建议使用 JWT 时只存 user_id + exp，权限判断逻辑全部放在服务端动态查库或缓存中。
- 每次接口入口调用 auth()->user() 获取当前用户对象，而不是读取 $_GET['user_id'] 或 $_POST['target_id']
- 禁止在 SQL 中直接拼接用户输入的 ID，例如 "SELECT * FROM orders WHERE user_id = {$_GET['id']}" 是高危写法
- 使用预处理语句 + 绑定参数，同时把当前用户 ID 作为查询条件的一部分，而非信任请求参数
数据归属校验必须落到每条记录
即使用户已登录且有“查看订单”权限，也不能默认允许他看所有订单。必须在查询时显式加入归属约束，确保返回的数据真正属于当前用户或其管理范围。
DESTOON B2B网站管理系统
下载
DESTOON B2B网站管理系统是一套完善的B2B(电子商务)行业门户解决方案。系统基于PHP+MySQL开发，采用B/S架构，模板与程序分离，源码开放。模型化的开发思路，可扩展或删除任何功能；创新的缓存技术与数据库设计，可负载千万级别数据容量及访问。
- 查询个人订单：WHERE user_id = ? AND id = ?，两个参数分别绑定当前用户 ID 和请求的订单 ID
- 管理员查看下属订单：先查出该管理员可管的 user_id 列表（如通过部门树或权限表），再用 WHERE user_id IN (1,5,8,12) 过滤
- 软删除场景下，务必加上 AND deleted_at IS NULL，避免越权恢复他人已删数据
操作级权限需动态判定，不硬编码角色
“admin”角色能删文章，不等于所有叫 admin 的账号都能删任意文章。应基于资源实例做细粒度判断，比如是否是作者、是否在编辑窗口期内、是否被锁定等。
立即学习“PHP免费学习笔记（深入）”；
- 删除前查数据库确认该文章的 author_id 是否等于当前用户 ID，或当前用户是否拥有 'delete_any_post' 权限
- 用策略类（Policy）或权限服务封装判断逻辑，例如 $policy->canDelete($currentUser, $post)，而不是 if ($role === 'admin')
- 敏感操作（如修改密码、转账）必须二次验证，比如要求重新输入密码或走短信/邮箱确认流程
日志与兜底机制不可省略
再严密的权限控制也可能漏掉边界情况。记录关键操作日志并设置异常响应，能在出问题时快速定位越权行为。
- 对所有涉及用户数据变更的操作（增删改查敏感字段）记录操作人、目标资源 ID、时间、IP、原始请求参数
- 当查询结果为空但请求参数看似合法时，不直接返回 404，而是统一返回 403，并记录可疑行为（比如用户 A 请求查看用户 B 的私有资料）
- 在数据库层启用行级安全策略（如 PostgreSQL 的 RLS）或视图隔离，作为应用层权限的补充防线
