-
-
Notifications
You must be signed in to change notification settings - Fork 666
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible duplication between 1.4.1 Access Control Architecture and 4.1.1 General Access Control Design #1031
Comments
Status: waits "scope definition" for V1 category (requirements). Related to #877 |
I try to move this forward. V1.4.1 and V4.1.1 are clear duplicates for me, if something specific is not hidden in terms like "trusted enforcement points" or "access control gateways".
Point for both is, don't check user permissions on the client side, as it is under client control and can not be trusted (can be bypassed). Both have CWE 602. Proposals:
V4.1.1 Verify that the application enforces access control rules on a trusted service layer,
I can see logic behind this, but I see those as separate problems and would like to keep separate requirements. If you make "single vetted checks" on client side, then you "pass the check" for that, but it is done in wrong place. |
How about: V4.1.1 Verify that the application enforces access control rules on a trusted service layer. Never enforce access controls on the client. |
"Never enforce access controls on the client." I think it's a bit too strong and may give some wrong signal - like you can not do something on the client side. The point is, you can do whatever on the client, just this is usability and you can not rely on that from security perspective. So maybe - "Never rely on access controls on the client." <- language checks/fixes needed |
That is not (at all) true. You cannot send sensitive data to the client that a user does not have access to and restrict the view of that data via client-side access control. This is a very common anti-pattern. The principle of least privilege rules here. Only send to the client what the user has access to. You simply cannot do effective access control client-site at all. |
I agree with sensitive data part, we have one pending requirement on that topic: #934 I talk more about frameworks like Angular, where there is classical solution, that all functionality is sent to the client, but then decisions what functionality to show and what not, are made on the client. |
I politely agree with that statement as well. Any intellectual property-based functionality like shipping routes, stock-trading AI, or other proprietary functionality needs to stay server-side a well. |
I still do not like the quote "Never enforce access controls on the client" it's not nuanced enough and I do get your point above @elarlang |
What about:
|
Maybe just untrusted layer? Term "client accessible" is confusing (at least for me), client can access (for reading) backend service as well. |
Reopen.
Was 1.4.1 kept because of some good reason or marking it as duplicate/removed was just accidentally left out from PR? |
Ugh, this whole thing is tricky. To me, 4.1.1 is the better wording but I actually think that because it is more conceptual rather than a specific control, I think it should belong in the architecture section 1.4. @elarlang do you disagree? |
For me V1 is just for documentation and decisions, if we need to/can check it from actual implementation, it should be out of V1. |
So would you prefer:
|
I prefer to get rid of 1.4.1, because in practice I can not see, what it gives extra or additionally to 4.1.1. We moved "conceptual" "Verify that input validation is enforced on a trusted service layer." also from 1.5.3 to 5.1.6. For me it's the same style. |
Ok, I opened #1372 to bin it |
1.4.1
Verify that trusted enforcement points, such as access control gateways, servers, and serverless functions, enforce access controls. Never enforce access controls on the client.
is very close to4.1.1
Verify that the application enforces access control rules on a trusted service layer, especially if client-side access control is present and could be bypassed.
in both cases I would recommend the developers to defer the authorization to something like the open policy agent (OPA).
Furthermore, 1.4.1 seems to be pretty close to 1.4.4
Verify the application uses a single and well-vetted access control mechanism for accessing protected data and resources. All requests must pass through this single mechanism to avoid copy and paste or insecure alternative paths.
I would again recommend using OPA in this case
The text was updated successfully, but these errors were encountered: