OWASP
1.4.5
Need to explain the term "attribute or feature-based access control" in this section header or summary.
This seems like a classic architecture level control where the conceptual basis is included in 1.4.x but the practical requirements are included in 4.x. Do you disagree @elarlang ?
V1.4 Access Control Architecture
| # | Description | L1 | L2 | L3 | CWE |
|---|---|---|---|---|---|
| 1.4.5 | Verify that attribute or feature-based access control is used whereby the code checks the user's authorization for a feature/data item rather than just their role. Permissions should still be allocated using roles. (C7) | ✓ | ✓ | 275 |
Current V4.1 General Access Control Design is missing requirement for checking attribute level permissions. Also related to issue https://github.com/OWASP/ASVS/issues/934
My point of views:
- V1 should contain at the end only documentation or business logical decision as requirement. If you need to check something from program code, it should be in some other more specific category
- we need to have separate requirement for checking attribute level permissions in V4.1
- if we want to use current V1.4.5, we can use it as (more clear) architecture requirement, and also in V4.1
I think that 1.4.5 is not something you explicitly need to check in the code but rather describing a specific AuthZ paradigm so I think it is fine.
What do you think of:
1.4.5
Verify that the access control mechanism checks a user's authorization for a specific application feature or data item based on a specific permission attribute rather than just based on the user's role.
1.4.x
Verify that the access control mechanism allocates permissions to users via roles rather than allocating the permission to the user directly.
What are the security risks in an application if it does not meet those requirements?
1.4.5, checking access control based on roles rather than permission attributes makes it more difficult to remove permissions from a role as the access control checking code is hardcoded to the role.
1.4.x risks having a huge mess of permission attributes added to users ad-hoc making it much harder to manage.
I think that 1.4.5 is not something you explicitly need to check in the code but rather describing a specific AuthZ paradigm so I think it is fine.
What do you think of:
1.4.5
Verify that the access control mechanism checks a user's authorization for a specific application feature or data item based on a specific permission attribute rather than just based on the user's role.
1.4.x
Verify that the access control mechanism allocates permissions to users via roles rather than allocating the permission to the user directly.
This is way better, than what is currently in the standard. The current wording is misleading, because it suggests, that only using ABAC or feature based access control (which is vague) will make the application compliant, when RBAC will work as well and is compliant with what you have written.
