Conversation
| * This does not replace the need to call `isAllowed` to determine if the user has | ||
| * access to perform the action. This is a tool that can be used to reduce the | ||
| * information disclosed (e.g. via timing-based probing) to users who don't have access | ||
| * to perform an action at all. |
There was a problem hiding this comment.
Because this is a more complex security subject, could we add an example scenario where this should be used, clearly showing where isAllowed is still needed?
Example: A request is made for budgets/it-dept/fy2025/q1. Your code needs to: (1) validate query params, and (2) load the IT Department budget for Q1 of FY2025 to see who has permission to view it (before an isAllowed call could be made). If the query params seem invalid, or if there is no budget for those params, you'd return a Bad Response or Not Found response. But, if the user doesn't have budget:View for any combination of departments, etc, then there's no reason to even perform those steps and potentially expose information through the Bad Request or Not Found responses.
Instead, you could follow this flow:
hasPolicyGranting('budget:View')- if they don't, then stop right there; if they do have a policy granting them view rights to a budget, it still may not be for this budget, but you can now continue your flow ...- validate query params; okay to return Bad Response
- look up the requested budget; may or may not be okay to return a 404 Not Found here, depending on your security requirements
- if you did find that budget item, now, check if they have permission to view this budget with
isAllowed
onebytegone
force-pushed
the
has-policy-granting
branch
from
b976856 to
52d7c49
Compare
2 participants
No description provided.