Authorization (AZ6)

The key concept for this card is applying authorization controls at the data level. See Authorization 5 (AZ5) for resource types controls, and Authorization 7 (AZ7) for function/object/property controls.

Scenario: Eduardo's Unauthorized Data Access Within Authorized Areas

Visualize a situation where Eduardo, despite having legitimate access to a certain form, page, URL, or entry point within an application, is able to access data beyond his authorized permissions. This happens due to:

1. Inadequate Granular Authorization Controls: The application does not enforce sufficient authorization checks at the data level, despite having controls at the page or form level.
2. Access Control Oversights: The system fails to differentiate between the authorization for accessing a page and the authorization for accessing specific data on that page.

Example

Eduardo has legitimate access to a report generation page in a corporate application. However, the page’s backend logic does not adequately verify his permissions for each data set available through the report generator. Eduardo exploits this oversight to access confidential data sets from the report generation tool, which he should not have access to based on his user role.

Threat Modeling

STRIDE

This scenario maps primarily to STRIDE: Elevation of Privilege.

Elevation of Privilege (EoP) occurs when an attacker accesses resources or data beyond what their role or permissions allow. Eduardo has legitimate access to the page (entry point), but the backend does not enforce proper data-level authorization, allowing him to access confidential data he shouldn’t. The core issue is improper enforcement of authorization at the data level, enabling privilege escalation within the context of an allowed page. The consequence of such an action leads to Information Disclosure in most cases.

What can go wrong?

Such gaps in authorization controls can lead to unauthorized data access, potentially resulting in information leakage, privacy breaches, and compliance violations. This can manifest in various forms, including but not limited to:

• Insecure Direct Object References (IDOR)
• Broken Object Level Authorization (BOLA)
• Unauthorized access to sensitive data through legitimate entry points

For more things that can go wrong, see the Common Attack Patterns related to this card in the table below.

What are we going to do about it?

Even though a user may be permitted access to a particular page, the contents of that page should also verify access control privileges. For example, a user should be able to edit their own profile text, but not that for another user.

1. Implement least privilege, and restrict users to only the data and system information that are required to perform their tasks.
2. Implement granular authorization checks that not only control access to pages and forms but also verify user permissions for each data set or action available within these entry points.
3. Regularly audit and update access control mechanisms to ensure they align with user roles and data sensitivity levels.
4. Conduct thorough security testing to identify and address any potential authorization bypass scenarios.
5. Ensure that data-specific access is restricted to users with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).

For detailed advice on how to mitigate threats related to the card, see the ASVS and OWASP Developer Guide requirements in the table below.