一、网站鉴权

1、网站的权限

网站权限是指网站或 Web 应用对用户设备、数据或浏览器功能的访问许可，用于规范网站能做什么、 不能做什么，既保障用户隐私与安全，也确保网站功能正常运行。

1.1 按用户角色分类

该分类基于 “最小权限原则”，不同角色对应不同操作范围，是最常见的权限划分方式。

1.2 按操作内容分类

该分类聚焦 “权限本身能做什么”，更偏向技术层面的权限定义。 **（1）功能权限：**控制是否能使用特定功能模块。

• 例如：是否能使用 “用户管理” 功能、是否能发起 “退款申请”、是否能进入 “后台管理系统”。

**（2）数据权限：**控制能访问或操作哪些范围的数据。

• 例如：普通编辑只能看自己的文章数据，管理员能看所有编辑的文章数据；部门经理只能看本部门的销售数据。

**（3）资源权限：**控制对网站具体资源的操作，通常细化到 “增删改查（CRUD）”。

• 例如：对 “文章” 资源，可单独设置 “创建文章”“删除文章”“修改文章”“查看文章” 四种权限。

2、Cookie鉴权

2.1 Cookie的介绍

Cookie（中文常称 “小甜饼”）是Web 服务器发送给浏览器的小型文本数据片段，存储在用户本地设备（电脑、手机等）上，本质是键值对（key-value）格式的文本文件，大小通常限制在 4KB 左右，主要用于在客户端与服务器之间传递状态信息，解决 HTTP 协议 “无状态” 的核心问题。

用户登录网站时，服务器会生成包含身份标识（如用户 ID、会话 ID）的 Cookie 发送给浏览器；后续用户访问该网站的其他页面时，浏览器会自动携带 Cookie，服务器通过验证 Cookie 即可确认用户已登录，无需重复输入账号密码

本质：Web 端身份验证机制，通过 客户端存储的 “身份标识（Cookie）” 维持用户登录状态。 核心逻辑：服务器生成标识→客户端保存→请求时自动携带→服务器验证。

2.2 Cookie鉴权步骤

（1）抓取登录数据包（2）观察cookie数据（3）按次序删去cookie里的参数，直到页面报错或者重定向（4）确定为cookie鉴权

3、请求头鉴权

3.1 请求头鉴权介绍

请求头鉴权是通过在 HTTP 请求头中携带 “身份凭证”（如 Token）来验证用户身份的机制，核心是“凭证自主携带、服务器验证有效性”，流程更灵活，适配前后端分离架构。

3.2 请求头鉴权步骤

（1）抓取登录数据包（2）有cookie先确定是否为cookie鉴权（3）确定不是cookie鉴权后，观察请求头里面是否特别的字段，Token、UA等（4）删除后会不会导致页面报错或者重定向（5）有报错或重定向则是请求头鉴权

二、越权攻击

1、越权攻击介绍

权限绕过也叫越权，一般是指低权限用户进行高权限的操作或平级操作。越权漏洞是一种很常见的逻辑漏洞。是由于服务器端对客户提出的数据操作请求过分信任，忽略了对该用户操作权限的判定，导致修改相关参数就可以拥有其他账户的增、删、查、改功能，从而导致越权漏洞。

2、 越权漏洞分类

水平越权 两个相同级别的用户A与用户B，用户B通过某种操作拥有了用户A的权限。

垂直越权 两个不同级别的普通用户A与管理员用户B，普通用户A通过某种操作拥有了管理员用户B的权限。

3、越权漏洞危害

水平越权会导致同一层级间的用户可以互相访问到对方的敏感信息，如姓名、手机号、联系地址、个人资料、订单记录等。同时还可能会以其他平级权限用户的身份来执行某项功能，如删除、添加、修改等。 垂直越权漏洞会导致低权限用户用来执行高权限用户的功能，获取高权限用户的账号信息、执行高权限用户的操作功能。

4、水平越权方法

水平越权的核心就一句话：服务器只验证了“你有没有登录”，没有验证“这东西是不是你的”。 所以我们只要用自己的合法身份，把请求里的“身份标识”换成别人的，服务器就会把别人的数据返回给我们、把操作作用到别人身上。

测试前必备：准备两个同级别的账号 A 和 B（例如注册两个普通用户）。这是所有水平越权测试的基础，没有第二个账号就没法对比验证。

合规提醒： 越权测试可能影响他人真实账户（如修改他人资料、删除他人数据），在 SRC/众测中动真实用户数据属于违规行为。务必只在自己注册的测试账号之间验证，千万不要拿真实用户的数据做写入类测试。

通用测试流程（两账号对比法）：

1. 用账号 A 登录，访问 A 自己的某个功能/数据，用 Burp 抓包；
2. 用账号 B 登录，做一模一样的操作，再抓一个包；
3. 对比 A、B 两个请求，唯一变化的那一个字段，通常就是身份标识（可能藏在 URL 参数、body 参数、请求头、Cookie 里）；
4. 把 A 请求里的身份标识改成 B 的值（其余字段、Cookie 保持 A 自己的不变）；
5. 重放请求——如果返回了 B 的数据、或操作成功作用到 B 身上，就存在水平越权。

下面按“身份标识藏在哪”分成三类。

4.1 请求头水平越权

是什么： 有些网站把用户标识放在 HTTP 请求头里，而不是 URL 参数里。常见字段有 X-User-Id、uid、userId、memberId、X-Id、Token 等。由于 Burp 默认重点看 URL 和 Cookie，请求头里的越权点经常被忽略，反而更容易挖到。

测试步骤：

1. 登录账号 A，抓取正常业务请求（如“查看个人资料”“查询余额”“我的订单”）；
2. 逐个检查请求头，找出疑似身份标识的自定义字段（名字里带 id / user / uid / member / account 的）；
3. 把该字段的值改成账号 B 的 id；
4. 重放请求，观察响应：
   • 返回了 B 的姓名/手机号/余额/订单 → 存在水平越权；
   • 返回报错或仍是 A 自己的数据 → 服务器没采用这个字段，换一个字段再试。
5. 辅助判断：把该字段整个删除再发，若报错、返回默认数据、或行为变化，说明服务器确实依赖它。

实例 1（查看资料）： 账号 A 查看自己资料的请求：

GET /api/user/profile HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA
X-User-Id: 1001

把 X-User-Id 改成 B 的 id 后重放：

GET /api/user/profile HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA
X-User-Id: 1002

响应却返回了 B 的完整资料（姓名、手机号、身份证、收货地址），而 Cookie 仍是 A 自己的——这就是典型的请求头水平越权：服务器用 X-User-Id 定位用户，却没校验它和登录态是否匹配。

实例 2（改收货地址）：

POST /api/user/address/update HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA
X-User-Id: 1001
Content-Type: application/json

{"address":"XX市XX区","phone":"138****0000"}

把 X-User-Id 改成 1002 后，成功把账号 B 的收货地址改掉了。

注意： 请求头越权的字段不限于 id，也可能是 Token/Authorization 里带了用户信息；测试时先对比 A、B 两个请求的差异字段，比盲目猜测更高效。

4.2 水平接管账号

是什么： 水平越权不只是“偷看数据”。如果越权点出现在改密码、换绑手机、换绑邮箱、重置密保这类敏感接口上，攻击者就能直接修改别人的账号凭据，把账号“接管”过来——这是水平越权危害最大的一档，一般按高危/严重上报。

测试步骤：

1. 先确定目标有哪些身份敏感操作：修改密码、绑定/换绑手机号、绑定/换绑邮箱、重置密保问题、找回密码等；
2. 用账号 A 抓取其中一个操作的请求；
3. 找到请求里的身份标识字段（参数、body、请求头、Cookie 都可能）；
4. 把身份标识改成账号 B 的，其余字段按“想对 B 做的操作”填写；
5. 重放请求，若返回成功，再用 B 的新密码/新手机尝试登录 B —— 登录成功即账号被接管。

实例（换绑手机 → 接管账号）： 账号 A 换绑手机的请求：

POST /api/user/bindPhone HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA
Content-Type: application/json

{"user_id":"1001","phone":"13900000000","sms_code":"888888"}

攻击者把 user_id 改成目标 1002，手机号填自己的：

{"user_id":"1002","phone":"13911111111","sms_code":"888888"}

服务器没有校验“user_id 是否等于当前登录用户”，直接把 1002 的绑定手机改成了攻击者的手机。之后攻击者用“短信验证码登录”即可登录 1002 的账号。

常见敏感接口自查清单：

注意： 换绑手机/邮箱接口往往会先校验短信/邮箱验证码，但很多站点只校验验证码对不对、不校验它是不是发给“当前登录用户”的，导致配合一个自己能收到的验证码就能把别人的绑定改掉。

4.3 控制ID越权

是什么： 最常见、最基础的一类水平越权。业务数据（订单、文章、消息、地址、发票等）通过一个可预测的 ID 来定位，攻击者直接遍历/修改这个 ID，就能访问到别人的数据。

测试步骤：

1. 用账号 A 登录，访问一个带 ID 的资源，抓包：

   GET /api/order/detail?order_id=202501010001 HTTP/1.1
   Host: www.example.com
   Cookie: session=AAAAAAA
   

2. 记下这个 ID，手动改一个相邻值（如 202501010002），或直接改成一个明显不属于自己的值；
3. 重放请求（其余字段、Cookie 保持 A 自己的不变）；
4. 判断：
   • 返回了别人的订单（姓名、地址、电话、金额）→ 水平越权；
   • 返回“无权限/订单不存在” → 服务器做了归属校验，这个点没洞；
   • 返回自己第一条数据/默认数据 → 可能只是没找到，换个 ID 再试。

实例（订单详情）：

GET /api/order/detail?order_id=202501010002 HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA

响应返回了另一位用户的订单：收货人姓名、手机号、家庭住址、商品明细、实付金额全部泄露。这是最典型的控制 ID 越权。

实例（收货地址遍历）：

GET /api/address/list?id=88 HTTP/1.1
Host: www.example.com
Cookie: session=AAAAAAA

把 id 从 1 遍历到 999，可以批量拉到所有用户的收货地址，属于批量数据泄露，危害更大。

进阶技巧：

1. ID 不一定纯数字。可能是 UUID、用户名、手机号、邮箱，甚至是加密/编码后的值（如 base64(用户id)）。看到一长串字符别放弃，先 base64 解一下、或对比 A/B 两账号的规律；
2. 批量遍历用 Burp Intruder。把 ID 参数标记为 §§，Payload 类型选 Numbers，设置起止范围，一次跑出所有响应，再按响应长度/关键字筛选出“命中别人数据”的；
3. 改 ID 时，自己的 Cookie/Token 千万别动。只改业务 ID、保留自己的登录态，这样才能证明是“越权”而不是“未登录也能访问”（后者是另一个漏洞——未授权访问，等级通常更高）；
4. 先看再写。查（读）接口的越权最常见，但别忘了改/删（写）接口同样能越权，危害更大，优先测。

5、垂直越权

5.1 垂直越权的场景

（1）管理功能未校验权限

• 普通用户直接访问管理员后台路径（如/admin/userManage）
• 调用管理员专属 API（如/api/admin/deleteUser）

（2）操作敏感功能无权限校验

• 低权限用户执行高权限操作（如普通用户删除系统日志、修改他人权限）
• 示例：某系统中，普通用户通过访问/api/setRole?userId=1&role=admin，将自己升级为管理员

（3）后台接口权限过滤不严

• 仅验证 "是否登录"，未验证 "是否为高权限角色"
• 示例：管理员接口仅判断user != null，而未校验user.role == 'admin'

5.2 垂直越权方法

垂直越权的核心一句话：服务器只校验了“你有没有登录”，没有校验“你是不是管理员”。 测试思路与水平越权正好相反——先用高权限账号把敏感操作的数据包抓下来，再换成低权限账号的身份重放，看低权限能不能执行成功。

测试前必备：两个不同权限等级的账号（一个普通用户 + 一个管理员）。管理员账号负责“采集”高权限功能的数据包，普通用户账号负责“重放验证”。如果实在拿不到管理员账号，也可以从 JS 文件、接口文档里收集疑似高权限接口（路径含 admin/manage/setRole/deleteUser 等关键字），直接用普通用户访问测试。

通用测试流程（高低权限对比法）：

1. 用高权限账号（管理员）登录，执行一个敏感操作（删用户、改角色、改配置），用 Burp 抓包，记住完整请求内容；
2. 退出管理员，登录低权限普通用户；
3. 把第 1 步抓到的请求里的身份凭证（Cookie/Token）换成低权限用户自己的，其余参数保持管理员请求原样；
4. 重放请求：
   • 操作成功、返回了高权限才有的数据 → 存在垂直越权；
   • 返回“权限不足/无权限” → 服务器做了角色校验，这个点没洞，换接口再试。

下面按常见绕过手法分类介绍。

（1）越权使用管理员功能

手法： 管理员能用的功能点，普通用户构造同样的请求也能用。本质是服务器只判断了“登录与否”，没判断“角色是否为管理员”。

测试步骤：

1. 管理员登录系统，找到仅管理员可见的功能（如用户管理里的“删除用户”）；
2. 执行一次删除操作，Burp 抓包，记录请求参数：

   GET /pages/vertical-privilege-escalation.php?action=delete&target_user_id=7 HTTP/1.1
   Host: www.example.com
   Cookie: PHPSESSID=管理员会话
   

3. 换成普通用户登录，把 Cookie 换成普通用户自己的，其余参数照抄，重放请求；
4. 若响应提示“成功删除用户ID: 7” → 普通用户拥有了管理员的删除权限，垂直越权成立。

变体： RESTful 风格的接口同样适用，直接对 /api/admin/deleteUser 这类“admin 专属”接口做同样的重放即可。

（2）修改请求方式绕过鉴权

手法： 后端只对 POST 请求挂了权限校验，GET 请求漏校验（或反之）。把敏感操作的请求方式改一下，即可绕过鉴权。

测试步骤：

1. 管理员登录，抓取“升级用户为管理员”的操作数据包，记住参数：username=user1&action=upgrade；
2. 切换普通用户 user2，用同样的参数构造请求 → 响应提示“权限不足，当前用户无权通过 POST 修改角色”；
3. 把请求方式改为 GET，参数不变，重放；
4. 响应提示“成功将用户 user2 升级为管理员” → 请求方式绕过成功，刷新浏览器页面验证角色已生效。

注意： 除了 POST→GET，也建议试 GET→POST、POST→PUT，以及 X-HTTP-Method-Override: GET 这类方法覆盖头——部分框架只给其中一种请求方式挂了鉴权中间件。

（3）请求头绕过鉴权

手法： 服务器信任某些请求头，或对某些头存在“后门逻辑”，伪造/添加特殊请求头即可绕过角色校验。

测试步骤：

1. 先抓取管理员的高权限操作包，再用普通用户身份重放，确认默认被拒绝；
2. 在请求中添加/修改可疑头后重试：
   • 自定义“后门头”：Auth: bypass、X-Admin: 1、X-Role: admin 等（部分系统为内部调试留了万能头）；
   • 伪造来源地址：X-Forwarded-For: 127.0.0.1、X-Real-IP: 127.0.0.1、Client-IP: 127.0.0.1（后端常信任这些头判断“是否内网/本地访问”，而内网接口往往不校验角色）；
   • Authorization 随便填个值，观察是否反而“跳过”了鉴权逻辑；
3. 若添加某个头后操作成功 → 请求头绕过成立。

注意： XFF 类伪造在真实生产环境可能被 CDN/WAF/Nginx 覆盖或触发告警，效果因链路而异，但值得一试；多 IP 链格式（X-Forwarded-For: 127.0.0.1, 192.168.1.1）也要测，不同后端取第一个还是最后一个 IP 结果不同。

（4）权限参数篡改

手法： 请求中存在直接标定权限等级的参数（URL、body、Cookie 里都可能有），把它改掉即可提权。

测试步骤：

1. 登录普通用户，逐个检查请求中疑似权限字段：role、isAdmin、admin、permission、level、type 等；
2. 尝试修改取值：role=user → role=admin、admin=0 → admin=1、isAdmin=false → isAdmin=true；
3. 重放请求，若返回高权限数据/功能（如用户管理列表、后台菜单）→ 存在垂直越权；
4. Cookie 里的权限字段同样要测：Cookie: user=guest; role=user 改成 role=admin；如果是 base64/URL 编码的值（如 Username=R3Vlc3Q=），先解码、改内容、再编码回去重发。

示例： 某系统普通用户通过访问 /api/setRole?userId=1&role=admin，直接将自己升级为管理员——这就是典型的“权限参数由客户端说了算”。

补充：前端校验绕过。 还有一种情况是权限判断只做在前端（按钮隐藏、路由拦截），后端没校验。这时可以用 Burp 拦截响应，把返回的 role: "user" 改成 role: "admin" 后放包，页面就会以管理员身份渲染。这严格说不是接口越权，但常与垂直越权配合使用，遇到“按钮是灰的但接口能调”的情况优先想到它。

（5）凭证替换法

手法： 拿到高权限请求样本后，只替换其中的身份凭证为低权限凭证，其余参数完全不动，重放看结果。这是判断服务端是否真正校验角色的最直接方法。

测试步骤：

1. 获得一个高权限请求样本（管理员操作时抓的包、JS 里的示例、历史流量均可）；
2. 只把其中的 Cookie/Token 替换成低权限用户自己的，其余完全保留；
3. 重放，若成功 → 该功能点只认“凭证有效”，不认“角色等级”，垂直越权成立。

（6）ID 置空越权

手法： 查询接口把“定位条件”参数（手机号、ID 等）置空或删除，后端拼接查询条件时落空，直接返回全量数据。严格说这是“未授权访问”与“垂直越权”的边界手法，但效果等同拿到了只有管理员才能看的数据全集，实战中常一起测。

测试步骤：

1. 找到一个按条件查询的接口（如“按手机号查用户”），正常传参确认有结果；
2. 把查询参数删除、置空字符串、或传 null（如 {"phone":""}）；
3. 若返回全量用户数据（姓名、手机号、邮箱等）→ 条件失效，等于越权查库。

5.3 垂直越权实战案例

案例 1：JS 接口泄露 + 普通用户直接调用 → 30w+ 数据泄露

某系统 JS 中泄露接口 /ssoms/cmms/api/sysUser/getUserList，普通登录用户直接构造请求调用，可获取全量用户列表（身份证、手机号、姓名、邮箱），共 30w+ 条数据：

GET /ssoms/cmms/api/sysUser/getUserList?json=%7B%22customQueryParams%22%3A%7B%22userName%22%3A%22%22,%22account%22%3A%22%22,%22roleId%22%3A%22%22,%22deptId%22%3A%22%22,%22levelCode%22%3A%22%22,%22currentUserId%22%3A%22%22%7D,%22page%22%3A%7B%22current%22%3A1,%22size%22%3A100%7D%7D&r=1758781808619 HTTP/1.1
Host: xxx.xxxx.org.cn
Cookie: 普通用户自己的会话

案例 2：伪造 Authorization + XFF 绕过

某接口未授权访问返回 401，构造 Authorization: 111111（任意值）配合 X-Forwarded-For: 127.0.0.1 等伪造头后，即可正常返回订单数据：

POST /api/order/orderInfo/pageNoDetail HTTP/1.1
Host: xxx.xxxx.cn
Authorization: 111111
X-Forwarded-For: 127.0.0.1
X-Originating-Ip: 127.0.0.1
X-Remote-Ip: 127.0.0.1
X-Remote-Addr: 127.0.0.1
Content-Type: application/json

{"page":10,"rows":10}

6、未授权访问

6.1 未授权原理

未授权访问（Unauthorized Access） 指用户在未经过身份验证或超出已授权范围的情况下，非法访问系统资源、数据或功能的安全漏洞。其核心原理是系统未对用户的访问请求进行有效身份验证或权限校验，导致攻击者可绕过正常认证流程（如未登录访问）或突破权限限制（如越权操作）。

6.2 未授权场景

（1）后台 / 管理界面未验证

• 后台登录页面可直接跳过，直接访问/admin等管理路径
• 示例：某系统的/admin/userList接口无需登录即可查看所有用户信息

（2）接口权限校验缺失

• API 接口未校验用户身份，直接返回敏感数据
  • 如/api/user/123可直接获取 ID=123 的用户手机号、地址等
• 功能接口未授权即可调用
  • 如/api/deleteUser?id=123无需权限即可删除用户

（3）JS / 接口文档泄露高权限接口

• 前端 JS 中硬编码了后台 API 路径，或 Swagger 等接口文档未关闭对外访问，攻击者无需登录即可拿到接口清单逐个尝试
• 示例：某系统 JS 中泄露 /api/lcplogics/selectProject 接口，未登录直接调用可获取所有审批信息

6.3 未授权访问漏洞实战

（1）访问网站 https://xxxxx.xxxyun.com/ ，发现无任何信息提示

（2）查看 js 文件，发现存在 api 接口泄露

/api/lcplogics/selectProject

（3）构造请求访问泄露接口信息，可获取所有审批信息，存在 projectid 泄露

POST /api/lcplogics/selectProject HTTP/2
Host: xxx.163yun.com
Cookie:
Content-Length: 22
Domainname: workflow
Lcap-Calllogic-Uuid: a86e72ded7f0479bbb0facebb54e894a
Sec-Ch-Ua-Platform: "Windows"
Timezone: Etc/GMT-8
Sec-Ch-Ua: "Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Ge
cko) Chrome/139.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
Lcap-Frontend: pc
Content-Type: application/json;charset=UTF-8
Origin: https://xxxx.163yun.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://xxxx.163yun.com/newReimbursement
Accept-Encoding: gzip, deflate, br Accept-Language: zh-CN,zh;q=0.9
Priority: u=1, i
Connection: keep-alive

{"userid":"122222222"}

（4）更换接口为 /api/lcplogics/applyFRLogin，复制 userid 进行访问

POST /api/lcplogics/applyFRLogin HTTP/2
Host: xxx.163yun.com
Cookie:
Content-Length: 21
Domainname: workflow
Lcap-Calllogic-Uuid: a86e72ded7f0479bbb0facebb54e894a
Sec-Ch-Ua-Platform: "Windows"
Timezone: Etc/GMT-8
Sec-Ch-Ua: "Not;A=Brand";v="99", "Google Chrome";v="139", "Chromium";v="139"
Sec-Ch-Ua-Mobile: ?0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Ge
cko) Chrome/139.0.0.0 Safari/537.36
Accept: application/json, text/plain, */*
Lcap-Frontend: pc
Content-Type: application/json;charset=UTF-8
Origin: https://xxxx.163yun.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://xxxx.163yun.com/newReimbursement
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9
Priority: u=1, i
Connection: keep-alive

{"userid":"65336fbd"}

可获取员工姓名、邮箱、手机号、密码信息、部门信息等，所有用户均可获取。此处 userid 只有 8 位数，可进行爆破；配合上个接口泄露的 2000+ 用户 id，可获取所有员工信息。

三、越权漏洞防御建议

1. 后端强制鉴权：每个接口独立验证用户身份与角色，不能依赖前端按钮隐藏/路由拦截做权限控制；
2. 数据归属校验：从 session/token 中取当前用户 ID，与请求中的资源 ID 做归属比对，不要直接信任客户端传的用户 ID；
3. 最小权限原则：按角色最小化分配权限，敏感接口（改角色、删用户、改配置）只对管理员开放并做双重校验；
4. 敏感操作二次验证：修改密码、换绑手机/邮箱、权限变更等操作要求重新输入密码或验证码；
5. 避免可预测资源 ID：业务资源 ID 使用不可预测的随机值（UUID），防止遍历枚举；
6. 统一请求方式校验：GET/POST/PUT/DELETE 都要挂同一套鉴权中间件，防止“改请求方式绕过”；
7. 不信任客户端头：不要用 X-Forwarded-For、Authorization 等客户端可控头做权限判断；若必须做 IP 限制，取真实连接 IP 并考虑代理链路；
8. 操作审计日志：权限变更、敏感操作记录完整审计日志，便于事后追溯。