示上将部分页面隐藏了。此时，恶意用户可以猜测其他管理页面的 URL，就可以访问或控制其他角色拥有的数据或页面，达到越权操作的目的，可能会使得普通用户拥有了管理员的权限。
解决：对管理员所见的管理界面 URL，每次用户访问时，都要判定该用户是否有访问此 URL 的权限。推荐使用成熟的权限解决方案框架。
3 水平权限（数据权限）
用户A和用户B可能同属于一个角色 RoleX，但用户 A 和用户 B 都各自有一些私有数据，正常情况下，用户自己只能访问自己的私有数据，例如：你有删除邮件的功能（操作权限），但只能删除自己的邮件，不能误删其他人的邮件（数据权限）。但在 RBAC 模型下，系统只会验证用户A是否属于角色 RoleX，而不会判断用户A是否能访问只属于用户B的数据 DataB，此时就可能发生越权访问。
这种问题，称之为『水平权限管理问题』，又可以称之为『基于数据的访问控制』：相比垂直权限管理来说，水平权限问题出现在同一个角色上，系统只验证了能访问数据的角色，没有对数据的子集做细分，因此缺乏了一个用户到数据级之间的对应关系。对于数据的访问控制，与业务结合的比较紧密，目前还没有统一的数据级权限管理框架，一般是具体问题具体解决。
数据权限就是控制访问数据的可见范围，表现形式是：当某用户有操作权限时候，不代表对所有数据都有查看或管理的权限。一般表现为行权限和列权限：
-
行权限：限制用户对某些行的访问，例如：只能对某人、某部门的数据进行访问；也可以是根据数据的范围进行限制，例如：按合同额大小限制用户对数据的访问
-
列权限：限制用户对某些列的访问，例如：某些内容的摘要可以被查阅，但详细内容只有 VIP 用户能查阅
水平权限的漏洞案例：Web应用程序接受用户的请求，修改某条数据id（资源的唯一编号）时，而没有判断当前用户是否可以访问该条记录，导致恶意用户可以修改本不属于自己的数据。例如：`/api/v1/blog?blogId=xxx [DELETE]` 这是删除博客内容的url，当用户改变 blogId 时，后端如果未校验博客的所属人是否是当前用户，则可以删除其他人的博客内容。
解决方案：用户做出相应动作时（新建、删除、更新等）时，需要对其会话身份进行验证（可采用Cookie机制），并且对用户访问的对象记录校验数据权限是否ok（按业务场景）。
4 OAuth
OAuth 是一个在不提供用户名和密码的情况下，授权第三方应用访问 Web 资源的安全协议。例如一个 OAuth 场景：用户将照片存储在Google，然后在"云冲印"的网站，将照片冲印出来。那么，"云冲印"网站需要获得用户的授权来读取Google上的用户照片。
OAuth 的一些名词：
-
Third-party application：第三方应用程序，又称 "Client" 客户端，上例中的"云冲印"网站
-
HTTP Service：HTTP服务提供商，上例中的Google
-
Resource Owner：资源所有者，就是用户
-
User Agent：用户代理，就是浏览器
-
Authorization server：认证服务器，即服务商提供商专门处理认证的服务器
-
Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器
OAuth 的授权流程：
A：用户打开第三方应用程序 Client，Client 要求用户给与授权
B：用户同意给予 Client 授权
C：Client 使用 B 步骤中获得的授权，向认证服务器申请令牌
D：认证服务器对 Client 进行认证之后，确认无误，同意发放令牌
E：Client 使用令牌，向资源服务器申请获取资源
F：资源服务器确认令牌无误之后，同意向 Client 开放资源
对于 B 步骤中的用户给 Client 第三方程序授权，OAuth2.0 定义了以下四种授权模式：
4.1 授权码模式（authorization code）
授权码模式是功能最完整、流程最严密的授权模式，它的特点是通过 Client 的后台服务器，与服务提供商的认证服务器进行交互
将每一步骤与所需的参数用时序图表示如下：
其中A.3中的scope是申请用户授权的权限范围，会向用户显示一个可授权列表，例如：获取用户信息、相册列表、点赞等资源，例如下图所示：
实例可参考：微信公众平台技术文档-微信网页授权
QQ互联-使用Authorization_Code获取Access_Token
4.2 简化模式（implicit）
简化模式不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了授权码的步骤。所有步骤都在浏览器中完成，令牌对访问者是可见的，且 Client 不需要认证
将每一步骤与所需的参数用时序图表示如下：
实例可参考：QQ互联-使用Implicit_Grant方式获取Access_Token
4.3 密码模式（resource owner password credentials）
密码模式中，用户向 Client 提供自己的用户名和密码，Client 使用这些信息，向服务提供商索要权限。这种模式中，用户需要将自己的密码提供给 Client，但 Client 处不得存储密码，这通常用于用户对 Client 高度信任的情况下，例如：Client 是操作系统的一部分或一个著名公司。而认证服务器只有在其他授权模式无法执行情况下，才会采用这种模式。
将每一步骤与所需的参数用时序图表示如下：
4.4 客户端模式（client credentials）
客户端模式，指 Client 以自己的名义，而不是以用户的名义，向服务提供商进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向 Client 注册，Client 以自己的名义要求服务提供商提供服务，其实不存在用户的授权问题。
将每一步骤与所需的参数用时序图表示如下：
