Authorization Cheat Sheet / 授权速查表¶

Introduction / 介绍¶

Authorization may be defined as "the process of verifying that a requested action or service is approved for a specific entity" (NIST). Authorization is distinct from authentication which is the process of verifying an entity's identity. When designing and developing a software solution, it is important to keep these distinctions in mind. A user who has been authenticated (perhaps by providing a username and password) is often not authorized to access every resource and perform every action that is technically possible through a system. For example, a web app may have both regular users and admins, with the admins being able to perform actions the average user is not privileged to perform, even though they have been authenticated. Additionally, authentication is not always required for accessing resources; an unauthenticated user may be authorized to access certain public resources, such as an image or login page, or even an entire web app.

授权可以定义为“验证请求的操作或服务是否被特定实体批准的过程”（NIST）。授权与身份验证不同，身份验证是验证实体身份的过程。在设计和发展软件解决方案时，牢记这些区别非常重要。经过身份验证的用户（可能通过提供用户名和密码）通常没有权限访问系统通过技术可能执行的所有资源和操作。例如，一个Web应用程序可能既有普通用户也有管理员，管理员可以执行普通用户无权执行的操作，尽管他们已经经过身份验证。此外，访问资源并不总是需要身份验证；未经身份验证的用户可能被授权访问某些公共资源，例如图片或登录页面，甚至整个Web应用程序。

The objective of this cheat sheet is to assist developers in implementing authorization logic that is robust, appropriate to the app's business context, maintainable, and scalable. The guidance provided in this cheat sheet should be applicable to all phases of the development lifecycle and flexible enough to meet the needs of diverse development environments.

本速查表的目的是帮助开发人员实现健壮、适合应用程序业务环境、可维护和可扩展的授权逻辑。本速查表中的指导应适用于开发生命周期的所有阶段，并且足够灵活，以满足不同开发环境的需求。

Flaws related to authorization logic are a notable concern for web apps. Broken Access Control was ranked as the most concerning web security vulnerability in OWASP's 2021 Top 10 and asserted to have a "High" likelihood of exploit by MITRE's CWE program. Furthermore, according to Veracode's State of Software Vol. 10, Access Control was among the more common of OWASP's Top 10 risks to be involved in exploits and security incidents despite being among the least prevalent of those examined.

与授权逻辑相关的缺陷是Web应用程序的一个显著关注点。在OWASP 2021年十大风险中，破坏访问控制被评为最令人担忧的Web安全漏洞，并被MITRE的CWE计划断言具有“高”利用可能性。Veracode的软件安全状态报告第10卷显示，尽管在检查的漏洞中相对较少见，但访问控制仍然是OWASP十大风险中最常见的漏洞之一，并涉及了许多安全事件。

The potential impact resulting from exploitation of authorization flaws is highly variable, both in form and severity. Attackers may be able to read, create, modify, or delete resources that were meant to be protected (thus jeopardizing their confidentiality, integrity, and/or availability); however, the actual impact of such actions is necessarily linked to the criticality and sensitivity of the compromised resources. Thus, the business cost of a successfully exploited authorization flaw can range from very low to extremely high.

授权漏洞被利用的潜在影响在形式和严重性上高度可变。攻击者可能能够读取、创建、修改或删除原本应该受到保护的资源（从而危及它们的机密性、完整性和/或可用性）；然而，这种行为的实际影响必然与受损害资源的紧迫性和敏感性相关。因此，成功利用授权漏洞的业务成本可能从非常低到极高不等。

Both entirely unauthenticated outsiders and authenticated (but not necessarily authorized) users can take advantage of authorization weaknesses. Although honest mistakes or carelessness on the part of non-malicious entities may enable authorization bypasses, malicious intent is typically required for access control threats to be fully realized. Horizontal privilege escalation (i.e. being able to access another user's resources) is an especially common weakness that an authenticated user may be able to take advantage of. Faults related to authorization control can allow malicious insiders and outsiders alike to view, modify, or delete sensitive resources of all forms (database records, static files, personally identifiable information (PII), etc.) or perform actions, such as creating a new account or initiating a costly order, that they should not be privileged to do. Furthermore, if logging related to access control is not properly set-up, such authorization violations may go undetected or at least remain unattributable to a particular individual or group.

未经身份验证的外部人员和经过身份验证（但不一定被授权）的用户都可以利用授权弱点。尽管非恶意实体的诚实错误或疏忽可能使授权绕过成为可能，但通常需要恶意意图才能完全实现访问控制威胁。水平权限提升（即能够访问其他用户的资源）是一个特别常见的弱点，经过身份验证的用户可能能够利用。与授权控制相关的错误可能允许恶意内部人员和外部人员 alike查看、修改或删除各种敏感资源（数据库记录、静态文件、个人身份信息（PII）等）或执行他们不应有权限执行的操作，例如创建新账户或发起昂贵的订单。此外，如果访问控制相关的日志设置不当，此类授权违规可能不会被检测到，或者至少无法归因于特定个人或团体。

Recommendations / 建议¶

Enforce Least Privileges / 强制最小权限¶

As a security concept, Least Privileges refers to the principle of assigning users only the minimum privileges necessary to complete their job. Although perhaps most commonly applied in system administration, this principle has relevance to the software developer as well. Least Privileges must be applied both horizontally and vertically. For example, even though both an accountant and sales representative may occupy the same level in an organization's hierarchy, both require access to different resources to perform their jobs. The accountant should likely not be granted access to a customer database and the sales representative should not be able to access payroll data. Similarly, the head of the sales department is likely to need more privileged access than their subordinates.

作为安全概念，最小权限原则是指只分配用户完成其工作所需的最小权限。尽管这个原则最常应用于系统管理，但它对软件开发人员同样适用。最小权限必须水平和垂直地应用。例如，尽管会计和销售代表可能在组织结构中处于同一级别，但他们都需要访问不同的资源来完成他们的工作。会计可能不应该被授予访问客户数据库的权限，而销售代表不应该能够访问工资数据。同样，销售部门的负责人可能需要比他们的下属更多的权限。

Failure to enforce least privileges in an application can jeopardize the confidentiality of sensitive resources. Mitigation strategies are applied primarily during the Architecture and Design phase (see CWE-272); however, the principle must be addressed throughout the SDLC.

未能强制执行应用程序中的最小权限原则可能会危及敏感资源的机密性。缓解策略主要在架构和设计阶段应用（参见CWE-272）；然而，这个原则必须在整个软件开发生命周期中加以解决。

Consider the following points and best practices:

请考虑以下要点和最佳实践：

During the design phase, ensure trust boundaries are defined. Enumerate the types of users that will be accessing the system, the resources exposed and the operations (such as read, write, update, etc) that might be performed on those resources. For every combination of user type and resource, determine what operations, if any, the user (based on role and/or other attributes) must be able to perform on that resource. For an ABAC system ensure all categories of attributes are considered. For example, a Sales Representative may need to access a customer database from the internal network during working hours, but not from home at midnight.
中文：在设计阶段，确保定义信任边界。列出将访问系统的用户类型、暴露的资源以及可能在这些资源上执行的操作（如读取、写入、更新等）。对于用户类型和资源的每一种组合，确定用户（基于角色和其他属性）是否必须能够执行该资源上的操作。对于ABAC系统，确保考虑所有属性类别。例如，销售代表可能需要在工作时间内从内部网络访问客户数据库，但不能在午夜从家中访问。
Create tests that validate that the permissions mapped out in the design phase are being correctly enforced.
中文：创建测试以验证设计阶段确定的权限是否被正确执行。
After the app has been deployed, periodically review permissions in the system for "privilege creep"; that is, ensure the privileges of users in the current environment do not exceed those defined during the design phase (plus or minus any formally approved changes).
中文：应用部署后，定期审查系统中的权限，以防止"权限蔓延"；即确保当前环境中用户的权限不超过设计阶段定义的权限（加减任何正式批准的变更）。
Remember, it is easier to grant users additional permissions rather than to take away some they previously enjoyed. Careful planning and implementation of Least Privileges early in the SDLC can help reduce the risk of needing to revoke permissions that are later deemed overly broad.
中文：记住，授予用户额外权限比剥夺他们之前享有的权限要容易。在SDLC早期阶段谨慎规划和实施最小权限原则可以帮助降低需要撤销权限的风险，这些权限后来被认为过于宽泛。

Deny by Default / 默认拒绝¶

Even when no access control rules are explicitly matched, the application cannot remain neutral when an entity is requesting access to a particular resource. The application must always make a decision, whether implicitly or explicitly, to either deny or permit the requested access. Logic errors and other mistakes relating to access control may happen, especially when access requirements are complex; consequently, one should not rely entirely on explicitly defined rules for matching all possible requests. For security purposes an application should be configured to deny access by default.

即使没有明确匹配的访问控制规则，当实体请求访问特定资源时，应用程序也不能保持中立。应用程序必须始终做出决定，无论是隐式还是显式地，拒绝或允许请求的访问。逻辑错误和其他与访问控制相关的错误可能会发生，尤其是在访问要求复杂时；因此，不应完全依赖明确定义的规则来匹配所有可能的请求。出于安全目的，应用程序应配置为默认拒绝访问。

Consider the following points and best practices:

请考虑以下要点和最佳实践：

Adopt a "deny-by-default" mentality both during initial development and whenever new functionality or resources are exposed by the app. One should be able to explicitly justify why a specific permission was granted to a particular user or group rather than assuming access to be the default position.
中文：在初始开发和每次应用暴露新功能或资源时，都应采取"默认拒绝"的心态。应该能够明确说明为什么授予特定用户或组特定的权限，而不是假设访问是默认位置。
Although some frameworks or libraries may themselves adopt a deny-by-default strategy, explicit configuration should be preferred over relying on framework or library defaults. The logic and defaults of third-party code may evolve over time, without the developer's full knowledge or understanding of the change's implications for a particular project.
中文：尽管一些框架或库可能本身采用默认拒绝策略，但应优先考虑显式配置，而不是依赖框架或库的默认设置。第三方代码的逻辑和默认设置可能会随着时间的推移而演变，而开发者可能没有充分的知识或理解这些变化对特定项目的影响。

Validate the Permissions on Every Request / 验证每个请求的权限¶

Permission should be validated correctly on every request, regardless of whether the request was initiated by an AJAX script, server-side, or any other source. The technology used to perform such checks should allow for global, application-wide configuration rather than needing to be applied individually to every method or class. Remember an attacker only needs to find one way in. Even if just a single access control check is "missed", the confidentiality and/or integrity of a resource can be jeopardized. Validating permissions correctly on just the majority of requests is insufficient. Specific technologies that can help developers in performing such consistent permission checks include the following:

应在每个请求上正确验证权限，无论请求是由AJAX脚本、服务器端还是其他来源发起。用于执行此类检查的技术应允许全局、应用程序范围内的配置，而不是需要单独应用于每个方法或类。记住，攻击者只需要找到一种进入的方式。即使只是遗漏了一个访问控制检查，资源的机密性和/或完整性也可能受到威胁。仅对大多数请求正确验证权限是不够的。以下是一些可以帮助开发者执行此类一致权限检查的特定技术：

Java/Jakarta EE Filters including implementations in Spring Security
Middleware in the Django Framework) （Django框架中的中间件）
.NET Core Filters) （.NET Core过滤器）
Middleware in the Laravel PHP Framework) （Laravel PHP框架中的中间件）

Thoroughly Review the Authorization Logic of Chosen Tools and Technologies, Implementing Custom Logic if Necessary / 彻底审查所选工具和技术的授权逻辑，如有必要，实施自定义逻辑¶

Today's developers have access to vast amounts of libraries, platforms, and frameworks that allow them to incorporate robust, complex logic into their apps with minimal effort. However, these frameworks and libraries must not be viewed as a quick panacea for all development problems; developers have a duty to use such frameworks responsibly and wisely. Two general concerns relevant to framework/library selection as relevant to proper access control are misconfiguration/lack of configuration on the part of the developer and vulnerabilities within the components themselves (see A6 and A9 for general guidance on these topics).

今天的开发者可以访问大量的库、平台和框架，这些框架和平台允许他们以最小的努力将强大、复杂的逻辑集成到他们的应用程序中。然而，这些框架和库不应被视为所有开发问题的快速万能药；开发者有责任负责任和明智地使用这些框架。与适当的访问控制相关，有两个一般性的关注点与开发者的配置错误/配置不足以及组件本身的漏洞有关（参见A6和A9以获取这些主题的一般指导）。

Even in an otherwise securely developed application, vulnerabilities in third-party components can allow an attacker to bypass normal authorization controls. Such concerns need not be restricted to unproven or poorly maintained projects, but affect even the most robust and popular libraries and frameworks. Writing complex, secure software is hard. Even the most competent developers, working on high-quality libraries and frameworks, will make mistakes. Assume any third-party component you incorporate into an application could be or become subject to an authorization vulnerability. Important considerations include:

即使在其他方面安全开发的应用程序中，第三方组件的漏洞也可能允许攻击者绕过正常的授权控制。这种担忧不应仅限于未经证实或维护不善的项目，它甚至会影响最稳健和最受欢迎的库和框架。编写复杂、安全的软件是困难的。即使是最有能力的开发者，在高质量库和框架上工作，也会犯错误。假设您将任何第三方组件集成到应用程序中时，都应该假定它可能或将成为授权漏洞的主题。重要的考虑因素包括：

Create, maintain, and follow processes for detecting and responding to vulnerable components.
中文：创建、维护并遵循检测和响应漏洞组件的流程。
Incorporate tools such as Dependency Check into the SDLC and consider subscribing to data feeds from vendors, the NVD, or other relevant sources.
中文：将依赖性检查等工具纳入SDLC，并考虑订阅来自供应商、NVD或其他相关来源的数据馈送。
Implement defense in depth. Do not depend on any single framework, library, technology, or control to be the sole thing enforcing proper access control.
中文：实施深度防御。不要依赖任何单一框架、库、技术或控制来执行适当的访问控制。

Misconfiguration (or complete lack of configuration) is another major area in which the components developers build upon can lead to broken authorization. These components are typically intended to be relatively general purpose tools made to appeal to a wide audience. For all but the simplest use cases, these frameworks and libraries must be customized or supplemented with additional logic in order to meet the unique requirements of a particular app or environment. This consideration is especially important when security requirements, including authorization, are concerned. Notable configuration considerations for authorization include the following:

配置错误（或完全缺乏配置）是开发者构建的组件可能导致授权失败的一个主要领域。这些组件通常是旨在具有相对通用目的的工具，旨在吸引广泛的受众。对于除最简单用例之外的所有用例，这些框架和库必须进行定制或补充以额外的逻辑，以满足特定应用程序或环境的独特需求。当涉及安全要求，包括授权时，这一考虑尤为重要。授权的显著配置考虑因素包括以下内容：

Take time to thoroughly understand any technology you build authorization logic upon. Analyze the technology's capabilities with an understanding that the authorization logic provided by the component may be insufficient for your application's specific security requirements. Relying on prebuilt logic may be convenient, but this does not mean it is sufficient. Understand that custom authorization logic may well be necessary to meet an app's security requirements.
中文：花时间彻底理解你构建授权逻辑所基于的任何技术。分析技术的功能，理解组件提供的授权逻辑可能不足以满足你应用程序的具体安全要求。依赖预构建的逻辑可能很方便，但这并不意味着它是足够的。理解，为了满足应用程序的安全要求，可能需要自定义授权逻辑。
Do not let the capabilities of any library, platform, or framework guide your authorization requirements. Rather, authorization requirements should be decided first and then the third-party components may be analyzed in light of these requirements.
中文：不要让任何库、平台或框架的能力引导你的授权需求。相反，授权需求应该首先确定，然后根据这些需求分析第三方组件。
Do not rely on default configurations.
中文：不要依赖默认配置。
Test configuration. Do not just assume any configuration performed on a third-party component will work exactly as intended in your particular environment. Documentation can be misunderstood, vague, outdated, or simply inaccurate.
中文：测试配置。不要假设在第三方组件上执行的任何配置都会在你的特定环境中完全按预期工作。文档可能被误解、模糊、过时或不准确。

Prefer Attribute and Relationship Based Access Control over RBAC / 优先使用基于属性和关系的访问控制而非基于角色的访问控制 (RBAC)¶

In software engineering, two basic forms of access control are widely utilized: Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC). There is a third, more recent, model which has gained popularity: Relationship-Based Access Control (ReBAC). The decision between the models has significant implications for the entire SDLC and should be made as early as possible.

在软件工程中，两种基本的访问控制形式被广泛使用：基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。还有一个更近期的模型，它已经获得了流行：基于关系的访问控制（ReBAC）。在模型之间的选择对整个SDLC有重大影响，并且应尽早做出决定。

RBAC is a model of access control in which access is granted or denied based upon the roles assigned to a user. Permissions are not directly assigned to an entity; rather, permissions are associated with a role and the entity inherits the permissions of any roles assigned to it. Generally, the relationship between roles and users can be many-to-many, and roles may be hierarchical in nature.
中文：RBAC是一种访问控制模型，其中访问权限是基于分配给用户的角色授予或拒绝的。权限不是直接分配给实体；相反，权限与角色相关联，实体继承分配给它的任何角色的权限。通常，角色与用户之间的关系是多对多的，并且角色可能是层次性的。
ABAC may be defined as an access control model where "subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions" (NIST SP 800-162, pg. 7). As defined in NIST SP 800-162, attributes are simply characteristics that can be represented as name-value pairs and assigned to a subject, object, or the environment. Job role, time of day, project name, MAC address, and creation date are but a very small sampling of possible attributes that highlight the flexibility of ABAC implementations.
中文：ABAC 可以定义为一种访问控制模型，其中 "主体请求对对象执行操作时，根据主体的分配属性、对象的分配属性、环境条件和一组以这些属性和条件为依据指定的策略进行授权或拒绝" (NIST SP 800-162, 第 7 页)。根据 NIST SP 800-162 的定义，属性仅仅是可表示为名称-值对的特性，可以分配给主体、对象或环境。职位角色、一天中的时间、项目名称、MAC 地址和创建日期只是可能属性的一小部分样本，突出了 ABAC 实现的灵活性。
ReBAC is an access control model that grants access based on the relationships between resources. For instance, allowing only the user who created a post to edit it. This is especially necessary in social network applications, like Twitter or Facebook, where users want to limit access to their data (tweets or posts) to people they choose (friends, family, followers).
中文：ReBAC是一种基于资源之间关系的访问控制模型。例如，只允许创建帖子的用户编辑它。这在社交网络应用中尤为重要，如Twitter或Facebook，用户希望将他们的数据（推文或帖子）的访问权限限制在他们选择的人（朋友、家人、关注者）身上。

Although RBAC has a long history and remains popular among software developers today, ABAC and ReBAC should typically be preferred for application development. Their advantages over RBAC include:

尽管RBAC有着悠久的历史，并且至今仍受到软件开发者的青睐，但通常应优先考虑ABAC和ReBAC进行应用开发。它们相对于RBAC的优势包括：

Support fine-grained, complex Boolean logic. In RBAC, access decisions are made on the presence or absence of roles; that is, the main characteristic of a requesting entity considered is the role(s) assigned to it. Such simplistic logic does a poor job of supporting object-level or horizontal access control decisions and those that require multiple factors.
中文：支持细粒度、复杂的布尔逻辑。在RBAC中，访问决策是基于角色的存在或不存在；也就是说，考虑请求实体的主要特征是分配给它的角色。这种简单的逻辑在支持对象级或横向访问控制决策以及需要多个因素的决策方面做得不好。
- ABAC greatly expands both the number and type of characteristics that can be considered. In ABAC, a "role" or job function can certainly be one attribute assigned to a subject, but it need not be considered in isolation (or at all if this characteristic is not relevant to the particular access requested). Furthermore, ABAC can incorporate environmental and other dynamic attributes, such as time of day, type of device used, and geographic location. Denying access to a sensitive resource outside of normal business hours or if a user has not recently completed mandatory training are just a couple of examples where ABAC could meet access control requirements that RBAC would struggle to fulfill. Thus, ABAC is more effective than RBAC in addressing the principle of least privileges.
  中文：ABAC大大扩展了可以考虑的特征数量和类型。在ABAC中，一个“角色”或工作职能当然可以是一个分配给主体的属性，但不必孤立地考虑（或者如果这个特征与请求的特定访问不相关，则根本不考虑）。此外，ABAC可以结合环境和其它动态属性，例如一天中的时间、使用的设备类型和地理位置。在正常工作时间之外拒绝访问敏感资源或如果用户未最近完成强制培训，这只是ABAC可以满足RBAC难以满足的访问控制要求的几个例子。因此，ABAC在处理最小权限原则方面比RBAC更有效。
- ReBAC, since it supports assigning relationships between direct objects and direct users (and not just a role), allows for fine-grained permissions. Some systems also support algebraic operators like AND and NOT to express policies like "if this user has relationship X but not relationship Y with the object, then grant access".
  中文：ReBAC支持分配直接对象和直接用户之间的关系（而不仅仅是角色），从而允许细粒度权限。一些系统还支持代数运算符，如AND和NOT，以表达策略，例如“如果这个用户与对象有X关系但没有Y关系，则授予访问权限”。
Robustness. In large projects or when numerous roles are present, it is easy to miss or improperly perform role checks (OWASP C7: Enforce Access Controls). This can result in both too much and too little access. This is especially true in RBAC implementations where a role hierarchy is not present and multiple role checks must be chained to have the desired impact (i.e., if(user.hasAnyRole("SUPERUSER", "ADMIN", "ACCT_MANAGER")) ).
中文：健壮性。在大型项目或存在众多角色的场景中，很容易遗漏或错误地执行角色检查 (OWASP C7: 强制访问控制)。这可能导致访问过多或过少。这在没有角色层次结构的 RBAC 实现中尤其如此，需要链式多个角色检查才能产生预期的影响（例如，if(user.hasAnyRole("SUPERUSER", "ADMIN", "ACCT_MANAGER"))）。
Speed. In RBAC, "role explosion" can occur when a system defines too many roles. If users send their credential and roles through means like HTTP headers, which have size limits, there may not be enough space to include all of the user's roles. A viable workaround to this problem is to only send the user ID, and then the application retrieves the user's roles, but this will increase the latency of every request.
中文：速度。在RBAC中，如果系统定义了太多的角色，可能会发生“角色爆炸”。如果用户通过HTTP头部等具有大小限制的途径发送其凭证和角色，可能没有足够的空间包括所有用户的角色。解决这个问题的一个可行方法是只发送用户ID，然后应用程序检索用户的角色，但这会增加每个请求的延迟。
Supports Multi-Tenancy and Cross-Organizational Requests. RBAC is poorly suited for use cases where distinct organizations or customers will need access to the same set of protected resources. Meeting such requirements with RBAC would require highly cumbersome methods such as configuring rule sets for each customer in a multi-tenant environment or requiring pre-provisioning of identities for cross-organizational requests (OWASP C7; NIST SP 800-162). By contrast, as long as attributes are consistently defined, ABAC implementations allow access control decisions to be "executed and administered in the same or separate infrastructures, while maintaining appropriate levels of security" (NIST SP 800-162, pg. 6).
中文：支持多租户和跨组织请求。RBAC 不太适合用于需要不同组织或客户访问同一组受保护资源的用例。在多租户环境中为每个客户配置规则集或为跨组织请求预先配置身份等高度繁琐的方法是满足此类要求的方法 (OWASP C7; NIST SP 800-162)。相比之下，只要属性定义一致，ABAC 实现允许访问控制决策 "在相同或不同的基础设施中执行和管理，同时保持适当的安全级别" (NIST SP 800-162, 第 6 页))。
Ease of Management. Although the initial setup for RBAC is often simpler than ABAC, this short-term benefit quickly vanishes as the scale and complexity of a system grows. In the beginning, a couple of simple roles, such as User and Admin, may suffice for some apps, but this is very unlikely to hold true for any length of time in production applications. As roles become more numerous, both testing and auditing, critical processes for establishing trust in one's codebase and logic, become more difficult (OWASP C7). By contrast, ABAC and ReBAC are far more expressive, incorporate attributes and Boolean logic that better reflects real-world concerns, are easier to update when access-control needs change, and encourages the separation of policy management from enforcement and provisioning of identities (NIST SP 800-162; see also XACML-V3.0 for a standard that highlights these benefits)
中文：易于管理。尽管 RBAC 的初始设置通常比 ABAC 简单，但这种短期利益随着系统规模和复杂性的增长而迅速消失。一开始，一些简单的角色，如用户和管理员，可能适用于某些应用程序，但在生产应用程序中，这很少能持续很长时间。随着角色的增多，测试和审计（建立代码库和逻辑信任的关键过程）变得更加困难 (OWASP C7)。相比之下，ABAC 和 ReBAC 表达能力更强，包含属性和布尔逻辑，更好地反映了现实世界的关注点，当访问控制需求发生变化时更容易更新，并鼓励将策略管理从执行和身份提供分离 (NIST SP 800-162; 参见 XACML-V3.0 以了解强调这些优势的标准))

Ensure Lookup IDs are Not Accessible Even When Guessed or Cannot Be Tampered With / 确保即使被猜到或无法篡改，查找 ID 也不可访问¶

Applications often expose the internal object identifiers (such as an account number or Primary Key in a database) that are used to locate and reference an object. This ID may be exposed as a query parameter, path variable, "hidden" form field or elsewhere. For example:

应用程序通常会公开用于定位和引用对象的内部对象标识符（例如账户号码或数据库中的主键）。此ID可能作为查询参数、路径变量、“隐藏”表单字段或其它地方公开。例如：

https://mybank.com/accountTransactions?acct_id=901

Based on this URL, one could reasonably assume that the application will return a listing of transactions and that the transactions returned will be restricted to a particular account - the account indicated in the acct_id param. But what would happen if the user changed the value of the acct_id param to another value such as 523. Will the user be able to view transactions associated with another account even if it does not belong to them? If not, will the failure simply be the result of the account "523" not existing/not being found or will it be due to a failed access control check? Although this example may be an oversimplification, it illustrates a very common security flaw in application development - CWE 639: Authorization Bypass Through User-Controlled Key. When exploited, this weakness can result in authorization bypasses, horizontal privilege escalation and, less commonly, vertical privilege escalation (see CWE-639). This type of vulnerability also represents a form of Insecure Direct Object Reference (IDOR). The following paragraphs will describe the weakness and possible mitigations.

In the example above, the lookup ID was not only exposed to the user and readily tampered with, but also appears to have been a fairly predictable, perhaps sequential, value. While one can use various techniques to mask or randomize these IDs and make them hard to guess, such an approach is generally not sufficient by itself. A user should not be able to access a resource they do not have permissions simply because they are able to guess and manipulate that object's identifier in a query param or elsewhere. Rather than relying on some form of security through obscurity, the focus should be on controlling access to the underlying objects and/or the identifiers themselves. Recommended mitigations for this weakness include the following:

Avoid exposing identifiers to the user when possible. For example it should be possible to retrieve some objects, such as account details, based solely on currently authenticated user's identity and attributes (e.g. through information contained in a securely implemented JSON Web Token (JWT) or server-side session).
Implement user/session specific indirect references using a tool such as OWASP ESAPI (see OWASP Top 10:2025 A01 Broken Access Control and the Insecure Direct Object Reference Prevention Cheat Sheet
Perform access control checks on every request for the specific object or functionality being accessed. Just because a user has access to an object of a particular type does not mean they should have access to every object of that particular type.

Enforce Authorization Checks on Static Resources¶

The importance of securing static resources is often overlooked or at least overshadowed by other security concerns. Although securing databases and similar data stores often justly receive significant attention from security conscious teams, static resources must also be appropriately secured. Although unprotected static resources are certainly a problem for websites and web applications of all forms, in recent years, poorly secured resources in cloud storage offerings (such as Amazon S3 Buckets) have risen to prominence. When securing static resources, consider the following:

Ensure that static resources are incorporated into access control policies. The type of protection required for static resources will necessarily be highly contextual. It may be perfectly acceptable for some static resources to be publicly accessible, while others should only be accessible when a highly restrictive set of user and environmental attributes are present. Understanding the type of data exposed in the specific resources under consideration is thus critical. Consider whether a formal Data Classification scheme should be established and incorporated into the application's access control logic (see here for an overview of data classification).
Ensure any cloud-based services used to store static resources are secured using the configuration options and tools provided by the vendor. Review the cloud provider's documentation (see guidance from AWS, Google Cloud and Azure for specific implementation details).
When possible, protect static resources using the same access control logic and mechanisms that are used to secure other application resources and functionality.

Verify that Authorization Checks are Performed in the Right Location¶

Developers must never rely on client-side access control checks. While such checks may be permissible for improving the user experience, they should never be the decisive factor in granting or denying access to a resource; client-side logic is often easy to bypass. Access control checks must be performed server-side, at the gateway, or using serverless functions (see OWASP ASVS 4.0.3, V1.4.1 and V4.1.1)

Exit Safely when Authorization Checks Fail¶

Failed access control checks are a normal occurrence in a secured application; consequently, developers must plan for such failures and handle them securely. Improper handling of such failures can lead to the application being left in an unpredictable state (CWE-280: Improper Handling of Insufficient Permissions or Privileges). Specific recommendations include the following:

Ensure all exception and failed access control checks are handled no matter how unlikely they seem (OWASP Top Ten Proactive Controls C10: Handle all errors and exceptions). This does not mean that an application should always try to "correct" for a failed check; oftentimes a simple message or HTTP status code is all that is required.
Centralize the logic for handling failed access control checks.
Verify the handling of exceptions and authorization failures. Ensure that such failures, no matter how unlikely, do not put the software into an unstable state that could lead to authorization bypass.
Ensure sensitive information, such as system logs or debugging output, is not exposed in error messages. Misconfigured error messages can increase the attack surface of your application. (CWE-209: Generation of Error Message Containing Sensitive Information)

Implement Appropriate Logging¶

Logging is one of the most important detective controls in application security; insufficient logging and monitoring is recognized as among the most critical security risks in OWASP's Top Ten 2021. Appropriate logs can not only detect malicious activity, but are also invaluable resources in post-incident investigations, can be used to troubleshoot access control and other security related problems, and are useful in security auditing. Though easy to overlook during the initial design and requirements phase, logging is an important component of holistic application security and must be incorporated into all phases of the SDLC. Recommendations for logging include the following:

Log using consistent, well-defined formats that can be readily parsed for analysis. According to OWASP Top Ten Proactive Controls C9, Apache Logging Services is one example of a project that provides support for numerous languages and platforms
Carefully determine the amount of information to log. This should be determined according to the specific application environment and requirements. Both too much and too little logging may be considered security weaknesses (see CWE-778 and CWE-779). Too little logging can result in malicious activity going undetected and greatly reduce the effectiveness of post-incident analysis. Too much logging not only can strain resources and lead to excessive false positives, but may also result in sensitive data being needlessly logged.
Ensure clocks and timezones are synchronized across systems. Accuracy is crucial in piecing together the sequence of an attack during and after incident response.
Consider incorporating application logs into a centralized log server or SIEM.

Create Unit and Integration Test Cases for Authorization Logic¶

Unit and integration testing are essential for verifying that an application performs as expected and consistently across changes. Flaws in access control logic can be subtle, particularly when requirements are complex; however, even a small logical or configuration error in access control can result in severe consequences. Although not a substitution for a dedicated security test or penetration test (see OWASP WSTG 4.5 for an excellent guide on this topic as it relates to access control), automated unit and integration testing of access control logic can help reduce the number of security flaws that make it into production. These tests are good at catching the "low-hanging fruit" of security issues but not more sophisticated attack vectors (OWASP SAMM: Security Testing).

Unit and integration testing should aim to incorporate many of the concepts explored in this document. For example, is access being denied by default? Does the application terminate safely when an access control check fails, even under abnormal conditions? Are ABAC policies being properly enforced? While simple unit and integration tests can never replace manual testing performed by a skilled hacker, they are an important tool for detecting and correcting security issues quickly and with far less resources than manual testing.