Mickey Martin
December 15, 2023
In today’s digitally-centric organizations, the development of products, services, and solutions increasingly depends on the implementation of Application Programming Interfaces (APIs). APIs facilitate effective communication, providing access to information and functionality associated with organizational data. In recent years, their usage has grown exponentially to the point where they are almost universal in both external-facing and internal applications. In summary, APIs have become one of the essential building blocks of modern business applications, and their use is critical to successful digital transformation. Consequently, API security must also be considered a fundamental business requirement at the boardroom level.
In the past, we have secured API by relying heavily on Coarse-grain authorizations and trust in a JWT token, and we have paid for this mistake. According to the latest OWASP report on Top API Security risks, organizations must revise this approach. We must evolve our strategy to care more about protecting the objects, digital assets, and data fabric serviced through the API rather than the API itself. In other words, we must apply Fine Grain Authorization to our APIs. We have to go behind PUT, POST, PATCH, GET, and DELETE and look at the question: Does this user or service have rights (or have authorization) to create, change, remove, or view the digital assets we provide to our employees, customers and third-party partners.
OWASP API REPORT
The OWASP API reports the top issues outlined below that we, as organizations, face today.
- API1:2023 – Broken Object Level Authorization
APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface of Object Level Access Control issues. Object-level authorization checks should be considered in every function that accesses a data source using an ID from the user.
- API3:2023 – Broken Object Property Level Authorization
This category combines API3:2019 Excessive Data Exposure and API6:2019 – Mass Assignment, focusing on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties.
- API5:2023 – Broken Function Level Authorization
Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.
- API6:2023 – Unrestricted Access to Sensitive Business Flows
APIs vulnerable to this risk expose a business flow – such as buying a ticket, or posting a comment – without compensating for how the functionality could harm the business if used excessively in an automated manner. This doesn’t necessarily come from implementation bugs.
- API8:2023 – Security Misconfiguration
APIs and the systems supporting them typically contain complex configurations, meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations, or don’t follow security best practices when it comes to configuration, opening the door for different types of attacks.
- API10:2023 – Unsafe Consumption of APIs
Developers tend to trust data received from third-party APIs more than user input, and so tend to adopt weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.
Summary:
Upon reviewing the top 10 OWASP API security risks, it becomes evident that we must expand our Zero Trust Strategies to encompass APIs. Zero Trust initially focused on the network, authentication, and device, emphasizing trust validation at every digital interaction. This validation involves ensuring that the calling user or service possesses the necessary authorization to access a specific digital asset. More than half of the report (API1, API2, API3, API5, API8, API10) emphasizes precisely this point. It’s not just about validating that a user or service has authorization for the API; it’s about authorizing access to the specific object it serves. It’s not merely trusting third-party services to perform their tasks but revalidating that trust on our end. It’s not solely trusting DevOps and software engineers to adhere to best practices within methods but enforcing validation before and after the method call itself.
How do we bring Zero Trust Strategies to our APIs, and how does one manage all the policies, all the APIs, and all the connections between users and digital assets?
The Strategy: ZERO TRUST
To bring Zero Trust Strategies to our APIs, we must first know that Zero trust architecture calls for identity-aware controls throughout the organization’s technology stack. Consequently, organizations must also consider identity-aware controls as part of their API access control strategy. It is essential to ask and answer critical questions before granting access, like:
- What is the user’s job role? E.g., are they a manager?
- What is the context of access? E.g., is the user accessing from the UK or China? What time is the user trying to access and does it make sense? Would a user from the UK usually be accessing information at 1am?
- What device is the user attempting to access the API from? Is it an approved device or an unsecured personal one?
It’s also important to look at what the user is trying to access and what the API call enables on their behalf. Identity-aware API access control doesn’t just consider the API itself but also what the API exposes to the user by understanding the full implication of this specific API usage at that point in time, in this context, and by this user. For example:
- What type of account is the user trying to access? Basic or VIP? Can they do that? Is the financial record they are trying to access associated with their account?
- Is the financial record they are trying to access associated with their account?
Adopting identity-aware API access control based on dynamic authorization is the only way an organization can genuinely follow zero-trust guidelines.
The Solution: PBAC The Strategy
“Policy-based Access Control,” a type of fine-grain authorization that focuses on creating, simulating, and governance of policies, can add identity-aware security and make the management of authorization policies possible. PBAC offers a business-oriented, comprehensive framework for centralized authorization management. This more flexible approach to authorization empowers application owners to create clear, adaptable policies that make sense within their organization’s specific needs. The increased adoption of this approach boils down to its business-friendly nature: far from slowing organizations down with difficult-to-understand restrictions and stumbling blocks, PBAC positions cybersecurity as a key business enabler that makes everyday tasks seamless and secure. A good PBAC strategy helps simplify and condense the number of policies needed to protect our digital assets serviced through APIs effectively.
The Solution: PBAC The Technology
Policy-based Access control isn’t just a fancy way to manage and view policies. It is coupled with technology, allowing those policies to be enforced in a distributed manner. This distributed enforcement is also vital in enabling our technology stacks’ API/microservice layers to have identity awareness. Looking at the API gateway layer and the layers below it, we can see how Policy-Based Access Control from PlainID can address the concerns of the OWASP API list.
The API Gateway Layer:
The API gateway layer, which the OWASP report focuses on, is typically protected with a coarse-grain authorization strategy that examines claims inside a JWT token to determine whether someone can access the root of an API. However, the OWASP report highlights the need for more robust security measures. These APIs serve an uncountable number of objects, and solely concentrating on protecting the root with coarse-grain authorization has proven inadequate in safeguarding data. By adopting a PBAC strategy that allows for fine-grained authorization, we can now make authorization decisions not solely based on a claim in a JWT but on the relationship between the entity calling the API and the specific object it services. While these objects are countless, the number of policies can be simplified to determine ‘who can access what and when.’ For example, Portfolio Managers can view, transact, and edit the Portfolios assigned to them. In this scenario, when the calling application forwards the user’s request and identity to the API gateway, an authorizer within the API gateway invokes a PDP to make a decision. During this process, the PDP collects identity data from the entire identity fabric and asset data or metadata from the data fabric to determine whether there is a valid reason to grant authorization to the request. These interactions align with the principles of OWASP and Zero Trust, emphasizing the need for dynamic trust evaluation.
The Micro Service Layer:
The microservice layer can adopt a two-pronged approach to secure transactions. While the OWASP report primarily addresses API protection, it also underscores the importance of enhancing security for objects serviced through APIs. To achieve this, we must extend this protection to the service meshes triggered after the API gateway. The microservice layer should be enhanced to perform authorization checks on North-South Traffic originating from the API gateway as well as East-West traffic (e.g., determining if microservice A should be allowed to call microservice B?). This focus on security addresses many of the concerns raised in the OWASP report regarding user-to-API security. It also addresses issues related to ensuring consistent security enforcement when developers or DevOps teams are involved. By introducing authorizers at both the proxy layer of the microservice layer and within the microservices themselves, we create a two-pronged approach that not only offers protection similar to the API gateway layer but also adds deeper data protection. This approach allows PBAC to control data retrieval from the data layer, specify what data can be accessed, and define the format of the data when it is transmitted. The microservice layer provides fine-grain control over transactions and the data/objects within them.
The Data Layer:
The data layer is located as far from the API Gateway layer as possible. However, to effectively safeguard digital assets, the OWASP API report emphasizes the necessity of implementing zero trust across every layer, including the data layer itself. APIs are designed to expose data, but it’s crucial to expose the right data at the right time. Establishing consistent, standardized protection from the API layer to the Data layer provides comprehensive security. Similar to the microservice layer, incorporating PBAC into the Data Access Layer introduces an additional security dimension to digital assets. Within the Data Layer, an Authorizer can analyze SQL commands, evaluate them in the context of identity, and determine whether they should be modified for security or blocked entirely. This represents the last line of defense against data over-exposure and is equally vital as the other layers in safeguarding an organization’s digital assets, specifically the objects exposed through the APIs.
Authorization Through the Layers:
As digital transformation initiatives expand remote access to more data and resources, attack vectors become increasingly vulnerable. Consequently, organizations must consider all aspects when securing their APIs, including identifying the APIs currently in use. However, basic API protection is no longer sufficient in a world where even minor breaches can have catastrophic consequences. Emphasizing API access control is crucial as part of a comprehensive API security initiative founded on the principles of zero-trust security. Only through these measures can organizations ensure that users accessing sensitive information are indeed who they claim to be.
