Understanding Authorization

• Authorization is verifying that a requested action or service is approved for a specific entity.
• Authentication is verifying an entity's identity, and is distinct from authorization.
• An authenticated user may not be authorized to access every system resource or perform every possible action.
• Authentication is unnecessary for accessing public resources, such as images or login pages, or even an entire web app.
• Authorization flaws are a major concern for web apps, with Broken Access Control being ranked as the most concerning web security vulnerability in OWASP's 2021 Top 10.
• Exploitation of authorization flaws can result in attackers reading, creating, modifying, or deleting protected resources.
• Both unauthenticated outsiders and authenticated users can exploit authorization weaknesses.
• Horizontal privilege elevation is a common weakness where users access other users' resources, so logging related to access control should be properly set-up to avoid undetected authorization violations.
• Honest mistakes or carelessness may enable authorization bypasses, malicious intent is typically required for access control threats to be fully realized.
• Faults related to authorization control can allow malicious insiders and outsiders alike to view, modify, or delete sensitive resources or perform actions that they should not be privileged to do.

Enforce Least Privileges

• Least Privileges assigns users only the minimum privileges necessary to complete their job, applying both horizontally and vertically within an organization.
• Failure to enforce least privileges can jeopardize the confidentiality of sensitive resources.
• During the design phase, define trust boundaries, enumerate user types and resources, and determine necessary operations for each user-resource combination to ensure all categories of attributes are considered.
• Testing should validate that the permissions mapped out in the design phase are being correctly enforced.
• Permissions should be periodically reviewed to avoid "privilege creep," where privileges exceed what was defined during the design phase.
• It is easier to grant users additional permissions than to revoke existing ones.

Deny by Default

• Applications should deny access by default when no access control rules are matched, ensuring security and preventing logic errors.
• A "deny-by-default" mentality should be adopted during initial development and when exposing new functionality or resources.
• Explicit configuration is preferred over relying on framework or library defaults because third-party code logic and defaults may evolve without developer's knowledge.

Validate the Permissions on Every Request

• Permissions should be validated on every request, regardless of the source (AJAX, server-side, etc.).
• Global, application-wide configuration should be used for permission checks, with technologies such as Java/Jakarta EE Filters, Django Middleware, .NET Core Filters, and Laravel PHP Framework Middleware being used.

Thoroughly Review the Authorization Logic of Chosen Tools and Technologies, Implementing Custom Logic if Necessary

• Developers need to responsibly use libraries, platforms, and frameworks, recognizing that misconfiguration or vulnerabilities within components can lead to broken authorization.
• Awareness of vulnerable components can be aided via tools like Dependency Check and data feeds from vendors or the NVD.
• Defense in depth to prevent dependencies on a single framework, library, technology, or control is needed to enforce proper access control.
• Thorough consideration of authorization is needed, realizing that prebuilt logic may be insufficient, with custom logic potentially being necessary to meet unique requirements.
• Authorization requirements and configurations should be tested.

Prefer Attribute and Relationship Based Access Control over RBAC

• Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Relationship-Based Access Control (ReBAC) are three basic forms of access control.
• RBAC grants or denies access based on assigned user roles, whereas ABAC grants or denies access based on attributes of the subject, object, environment, and policies.
• ReBAC is an access control model that grants access based on the relationships between resources
• ABAC and ReBAC are generally preferred over RBAC due to their support for fine-grained logic, robustness, support for multi-tenancy and cross-organizational requests, and ease of management.
• ABAC expands the number and type of characteristics considered, incorporating environmental and dynamic attributes beyond just roles.
• ReBAC grants access based on the relationships between resources and direct users (and not just a role), allowing for fine-grained permissions.

Ensure Lookup IDs are Not Accessible Even When Guessed or Cannot Be Tampered With

• Applications should avoid exposing internal object identifiers (lookup IDs) to users, as this can lead to authorization bypasses and privilege escalation.
• The focus should be on controlling access to the underlying objects and/or identifiers, not relying on security through obscurity.
• Identifiers should be avoided when possible and implement user/session specific indirect references can be used.
• Access control checks on every request for the specific object or functionality being accessed should be implemented.

Enforce Authorization Checks on Static Resources

• Static resources must be incorporated into access control policies, with protection varying based on the resource type and data exposed.
• Cloud-based services to store static resources should be secured using vendor-provided configuration options and tools.
• The same access control logic and mechanisms used to secure other application resources and functionality should be implemented to protect static resources.

Verify that Authorization Checks are Performed in the Right Location

• Client-side access control checks should be avoided, as they can easily be bypassed and should not be the deciding factor in granting or denying access to a resource.
• Access control checks must be performed server-side, at the gateway, or using serverless functions.

Exit Safely when Authorization Checks Fail

• Developers should plan for and securely handle failed access control checks to avoid leaving the application in an unpredictable state.
• Exceptions and failed access control checks should be handled, and logic for failed checks should be centralized.
• Handling of exception and authorization failures should be verified to ensure stability.
• Sensitive information should not be exposed in error messages.

Implement Appropriate Logging

• Logging is crucial for detecting malicious activity, post-incident investigations, troubleshooting, and security auditing.
• Logging should use consistent, well-defined formats, with careful consideration of the amount of information to log.
• Clocks and timezones should be synchronized across systems, and application logs should be incorporated into a centralized log server or SIEM.

Create Unit and Integration Test Cases for Authorization Logic

• Unit and integration tests are essential for verifying that an application performs as expected, especially for access control logic.
• Testing should incorporate concepts such as denying access by default, safe termination on failed checks, and proper enforcement of ABAC/ReBAC policies.
• Unit and integration testing of access control logic can help reduce the number of security flaws that make it into production, but not more sophisticated attack vectors.