CSRF漏洞核心在于浏览器自动携带Cookie导致服务器无法验证请求来源，攻击者借此伪造用户已登录态下的非本意请求；防御需结合CSRF Token、SameSite属性、双重提交Cookie及Origin/Referer校验等多层机制。
PHP越权访问漏洞的核心问题在于：服务端未对当前用户的身份权限做严格校验，就直接执行了敏感操作或返回了本不该看到的数据。它不依赖技术漏洞利用，而是绕过逻辑防线——比如普通用户篡改URL里的user_id=123为user_id=124，就成功查看了别人的信息。
明确用户身份与资源归属关系
越权分水平（同角色间越权）和垂直（低权限冒充高权限），但修复起点一致：每次访问受控资源前，必须确认“这个用户是否有权操作这个具体资源”。不能只查“是不是登录了”，更不能只查“是不是管理员”就放行所有操作。
- 对用户专属数据（如个人资料、订单列表），查询时强制关联当前登录用户的ID。例如：
SELECT * FROM orders WHERE user_id = ? AND id = ?，两个参数都来自服务端可控来源（session中的uid + 经过滤的id） - 避免在URL或表单中直接暴露数据库主键。可用映射ID、UUID或加密ID替代裸露的数字ID，增加暴力遍历难度
- 对后台管理类接口，除判断角色外，还需校验操作目标是否在该管理员的管辖范围内（如部门ID匹配、所属门店一致）
统一权限校验入口，拒绝重复造轮子
把权限判断逻辑集中到中间层或基类方法中，而不是每个控制器里手写if ($user->role !== 'admin') die()。这样既减少遗漏，也便于审计和更新策略。
- 在框架路由或控制器构造函数中，调用统一的
canAccess($resource, $action)方法，传入当前请求的目标资源标识（如post:105、setting:email）和动作（view/edit） - 权限规则建议存于配置数组或数据库，支持按角色+资源+动作三元组定义，而非硬编码if-else
- 对API接口，尤其要校验
Authorization头后的真实用户身份，并在业务逻辑开始前完成资源级授权
敏感操作必须二次确认与日志留痕
即使权限校验通过，对关键行为（如删除账号、修改密码、资金转账）仍需额外防护层，防止会话劫持或误操作。
立即学习“PHP免费学习笔记（深入）”；
- 要求用户输入当前密码、短信验证码或进行图形验证，确保是本人实时确认
- 记录完整操作日志，包括操作人ID、目标资源ID、时间、IP、User-Agent，且日志不可被当前用户覆盖或删除
- 对高危操作提供“撤回窗口”，例如30秒内可取消刚提交的删除请求（需服务端状态支持）
前端限制 ≠ 权限控制
隐藏按钮、禁用链接、前端JS拦截，全部无效。攻击者可直接发HTTP请求绕过。所有校验必须在服务端完成，且基于可信上下文（如session、JWT payload），不能依赖客户端传来的任何标识字段。
- 禁止在前端JavaScript中拼接敏感接口URL并携带用户可控参数（如
/api/user/delete?id=${userId}） - AJAX请求同样需要完整服务端鉴权，不能因为是“内部调用”就跳过资源归属检查
- 使用CSP、Referrer-Policy等头部辅助防御，但它们只是纵深防御的一环，不能替代权限逻辑
