权限加固核心是“只放行明确需要的，其余一律拒绝”，需梳理关键业务路径、分层实施权限控制、杜绝默认权限与隐式信任，并建立权限变更闭环机制。
核心思路不是“给所有路径加权限”，而是“只放行明确需要的，其余一律拒绝”。权限加固的本质是收敛攻击面，让恶意访问在触达业务逻辑前就被拦住。
一、梳理并锁定关键业务路径
先明确哪些路径真正承载核心业务，避免加固范围过大或遗漏重点：
- 登录、密码重置、API密钥生成等身份类接口（如 /login、/api/v1/token/refresh）
- 数据导出、批量操作、配置修改等高危管理路径（如 /admin/export、/settings/update）
- 第三方回调、Webhook接收端点（如 /callback/payment、/webhook/slack）
- 静态资源上传入口（如 /upload/avatar、/api/v1/document），尤其需防范文件上传漏洞
建议用日志+流量分析工具（如Nginx access log + awk 或 ELK）统计近30天真实被调用的路径，剔除测试、废弃、未文档化的“幽灵接口”。
二、分层实施权限控制策略
单一层级防护容易被绕过，必须在多个环节叠加验证：
- 网络层：用防火墙或云安全组限制访问源IP。例如，仅允许运维网段访问 /admin，禁止公网直连数据库管理后台
- 接入层（WAF/反向代理）：对敏感路径强制校验请求头（如 X-Auth-Type: jwt）、拦截无 Referer 或非 HTTPS 的请求；对上传路径限制 Content-Type 和文件后缀（如只允 .png,.pdf）
- 应用层：每个关键路径入口处做细粒度鉴权。不依赖全局中间件——比如 /api/v1/order/cancel 不仅要验登录态，还要校验当前用户是否为该订单所属人（owner_id == user_id）
三、杜绝默认权限与隐式信任
大量恶意访问成功，源于系统默认“允许”而非“拒绝”：
- 清理所有未声明用途的账号（如 MySQL 中的匿名用户、Linux 中的 test 用户），执行 DELETE FROM mysql.user WHERE User = '';
- 禁用开发环境遗留功能：关闭 Swagger UI 生产环境访问、注释掉调试路由（如 /debug/pprof）、移除 phpinfo() 页面
- API 接口不返回冗余字段：订单接口不返回用户银行卡号、身份证号等敏感信息，哪怕前端没用也要服务端过滤
- 文件系统权限收紧：Web 目录禁止写入（chown root:www-data /var/www/html && chmod 755），上传目录单独设为可写但不可执行
四、建立权限变更闭环机制
权限不是设一次就完事，必须持续验证和审计：
- 每次上线新接口或调整路径权限，同步更新权限矩阵表（含路径、所需角色、最小权限、审批人）
- 每周自动扫描：用脚本检查是否存在 目录遍历（../）、未授权访问（401/403缺失）、越权读写（ID横向越权） 等问题
- 关键路径操作留痕：记录谁、何时、从哪台设备、以什么权限触发了 /admin/user/delete，日志至少保留180天
