主要表现
强制执行访问控制策略，
使用户无法执行超出其预期权限。失败策略通常会导致未经授权的信息披露、修改或销毁或执行超出用户权限的业务功能。
常见的访问控制漏洞包括：
通过修改URL，内部应用程序状态，或者HTML页面绕过访问控制检查，或者使用自定义API 攻击工具。
允许将主键更改为其他用户记录，允许查看或编辑他人的帐户。
特权提升。在没有登录的情况下充当用户，或以用户身份登录时充当管理员。
元数据操作，例如重放或篡改JSON Web令牌（JWT）访问控制令牌或操作的cookie或隐藏字段以提升权限或滥用JWT无效
CORS配置错误允许未经授权的API访问
强制浏览经过身份验证的页面作为未经身份验证的用户，或访问特权页面作为标准用户。访问API缺少POST，PUT和DELETE的访问控制
预防方法
访问控制仅在受信任的服务器端强制执行时才有效
代码或无服务器API，攻击者无法修改
访问控制检查或元数据。
除公共资源外，默认拒绝
实施一次访问控制机制并重新使用它们，整个应用程序，包括最小化CORS使用
模型访问控制应该强制执行记录所有权，而不是接受用户可以创建，阅读，更新或删除，任何记录
应具有独特的应用程序业务限制要求，由域模型强制执行
禁用Web服务器目录列表并确保文件元数据（例如.git）和备份文件不存在于Web根目录中
记录访问控制失败，在适当时提醒管理员（例如重复失败）。
速率限制API和控制器访问，以最大限度地减少伤害自动攻击工具
注销后，JWT令牌应在服务器上失效。开发人员和QA人员应包括功能访问控制
单元和集成测试
常见方法
DAC
MAC
RBAC
ABAC
访问控制设计原则
- 开发初始前彻底设计好访问控制
一旦您选择了一个特定的访问控制设计模式，这通常是困难和耗时时使用新模式重新设计应用程序中的访问控制。访问控制是应用程序安全设计的主要领域之一，必须彻底预先设计，特别是在满足多租户和水平（数据相关）访问控制。
访问控制设计可以从简单的开始，但通常会发展为复杂的、功能丰富的安全控制。在评估软件框架的访问控制能力时，确保您的访问控制功能将允许为您的特定访问进行自定义控制功能需要。
- 强制所有请求进行访问控制检查
确保所有请求都经过某种访问控制验证层。诸如Java过滤器或其他自动请求处理机制的技术是理想的程序组件，有助于确保所有请求通过某种访问控制检查。
- 默认拒绝
默认情况下，拒绝是一个原则，即如果请求不被特别允许，它将被拒绝。这条规则在应用程序代码中有许多体现方式。
其中的一些例子是：
应用程序代码在处理访问控制时可能引发错误或异常请求。在这些情况下，应始终拒绝访问控制。
当管理员创建新用户或用户注册新帐户时，在配置该访问之前，默认情况下，帐户应具有最小或无访问权限。
向应用程序添加新功能时，应拒绝所有用户使用该功能。直到他正确配置了。
- 最小权限原则
确保仅以最少或尽可能少的方式提供所有用户，程序或进程访问权限。警惕不提供细粒度访问控制的系统配置功能。
- 不要硬编码角色
许多应用程序框架默认为基于角色的访问控制。这是常见的查找用这种性质的检查填充的应用程序代码。
if (user.hasRole("ADMIN")) || (user.hasRole("MANAGER")) {
deleteAccount();
}
在代码中注意这种基于角色的编程。它有以下限制或者危险。
这种基于角色的编程是脆弱的。在代码中很容易造成错误或缺少
对角色检查。
基于角色的编程不适用于多租户。极端措施如
需要为每个客户分配代码或添加支票,
基于角色系统，需要为不同的客户提供不同的规则。
基于角色的编程不允许对特定数据或水平访问做控制。
具有许多访问控制检查的大型代码库可能难以审计或验证总体应用程序访问控制策略。
相反，请考虑以下访问控制编程方法：
if (user.hasAccess("DELETE_ACCOUNT")) {
deleteAccount();
}
这种基于属性或者功能的访问控制检查是
建设设计完善、功能丰富的门禁系统。这种程序设计
还允许随着时间的推移提供更大的访问控制自定义功能
- 记录所有访问控制事件
应记录所有访问控制失败，因为这些可能表示恶意用户
探测应用程序的漏洞。
