API Security: 5 lessons from my experiences

API (Application Programming Interface) plays a central role in today’s digitally connected world. A recent Akamai report reveals that over 80% of current internet traffic constitutes API interactions. This trend is showing no sign of slowing down as more and more enterprises are joining the bandwagon to expose their capabilities in form of APIs. This surge underscores the critical need for robust API security practices.

Recognizing this burgeoning importance, OWASP (Open Web Application Security Project) even maintains a dedicated top ten list specifically focusing on API security risk. This highlights the growing concern around API vulnerabilities, leaving a vast attack surface for malicious actors to exploit.

Drawing from real-world experiences, this article explores 5 prominent challenges faced in today's API programs, along with potential solutions:

1. Lack of API Vision & API Proliferation

• Challenge: Organizations lack a clear vision (why) and strategy (how) for their API program. In many cases, it is vaguely defined and poorly understood by the delivery teams. This results in every project tends to create their own "narrowly defined" APIs, leading to a cluttered and difficult-to-manage API inventory.
• Solution: Develop a well-defined API strategy, clearly outlining the purpose and approach (e.g. Product Agnostic or LOB agnostic etc). Treat your APIs as products and invest upfront in creating an “API map” that identifies potential APIs. This API map needs to be refined periodically to align with the business strategy, but this should be the north star for projects to remain closely aligned. Anything outside this API map must be explicitly declared and agreed.
• My Experience: “One of the organizations I consulted, the API strategy just mentioned that we want to expose all our capabilities via APIs (inspired by Jeff Bezos), but failed to clarify what, why and how part in the API Strategy document. They went to the extent that all IT directors had “# of APIs delivered” as their annual performance goal. You can imagine that every director was only looking for ways to expose more APIs (number matters), irrespective whether there is any use of it or not. This resulted in more than 500 APIs (of all shapes and sizes) in less than 2 years and they have to launch an assessment initiative to rationalize them.“

2. Not All APIs Are Created Equal

• Challenge: The are different types of APIs viz Experience, Process, Domain, System etc. They have a specific positioning and role to play. Lack of clear API layering, allowed (and prohibited) interaction patterns and initial enablement to guide team on their journey to create APIs, leads to all sorts of interaction/integration patterns mushroomed in the enterprise. One you have a spaghetti, securing these API and applying right policies become a humongous task.
• Solution: Define and enforce a clear API layering strategy with specific guidelines and security considerations for each layer. This helps maintain consistency and simplifies management.
• My Experience: “In one instance customer was running a large transformation program with huge emphasis on APIfication. The Enterprise architecture team has clearly articulated API types and their potential interaction patterns. However, the enforcement was left to the individual platforms and solution architects without much of common governance.After 18 months into the program, they invited us to conduct assessment of their API program. We started analyzing APIs and categorizing available APIs in the defined layers and started drawing their interactions, we realized that all sorts of communication patterns are implemented, and many a times naming (based on layer) is not matching up with the actual intent and positioning. Additionally, in such situation it was extremely difficult to consistently know where the security is enforced.”

3. The "Reuse Trap"

• Challenge: Reuse is desirable quality of API, but blindly applying the "reuse" principle across all API types (e.g. Experience or Channel APIs) can lead to complex security policies and unintended vulnerabilities. You can also call this issue as mixing up of multiple channel traffic via single proxies.
• Solution: Evaluate each API layer’s suitability for reuse based on its purpose and potential security implications. Domain APIs benefit from broader reuse, while other types like Experience or Channel APIs might require a more targeted approach. Prioritize dedicated APIs for specific channels when necessary to avoid compromising security.
• My Experience: “In one of my recent projects, we had a Channel API to “fetch customer payment history” (Public URI: /customer/paymentHistory) exposed to the customer self-service app. It was a protected API. It will validate customer’s identity (access token) and adding the user context (Internal URI: /customer/paymentHistory?customerAccount=xyz) before passing on to subsequent microservices to fetch the payment history.Few months later, client started with another program to modernize Agent Portal and the solution architect had a great idea to reduce the effort by reusing the same channel APIs that are already built for customer self-service app. Now, APIs were designed to work with the User Context cannot directly be reused because in context of Agent Portal, it was Agent’s identity rather than Customer’s identity. It was decided to “enhance” this API to increase its reuse factor. To make it reusable by agent portal, a "Customer Account Number" (Public URI: /customer/paymentHistory?customerAccount={}) parameter was added in the request parameter list.While this might look like a trivial change, it opened a significant security gap. The API, originally working by enriching the customer account number at API Gateway now accepts this information as a parameter and no additional validation can be applied because now it supports both Customer Identity and Agent Identity.Fortunately, during an internal review this issue was caught and rectified.”

4. Mind the Gap

• Challenge: Different teams responsible for API Gateway (exposure) and API implementation (e.g., microservices) often operate in silos, leading to potential security gaps due to differing assumptions and expectations.
• Solution: Foster collaboration and clear communication between API Gateway and implementation teams. Establish a joint forum to ensure alignment on security responsibilities and expectations throughout the API lifecycle.
• My Experience: “In one of the large scale transformation program, we had centralized team for API Gateway and multiple teams for the domain centric API Implementation. Guidance from Enterprise architecture team was to leverage API Gateway as the security policy enforcement point. The API implementation team assumed that security (authenticating and authorizing request) is API Gateway team's responsibility, so they implemented little to none security measures within their microservices. The Gateway team, unaware of the security coverage within microservices, only applied minimum technical security policies suitable for simple cases (e.g. token validation etc). This approach worked for the initial bunch of APIs, because they were read only Public APIs, but as the system grew more complex and we started adding more functional APIs, security vulnerabilities started emerging during testing phase (e.g. API1:2023 - Broken Object Level Authorization etc).Eventually, a dedicated cross functional team was formed to look at the security from end-to-end rather than in piecemeal. Additionally, a forum was setup between gateway and microservices team to ensure clear communication and shared responsibility for security across all API scenarios.”

5. Loosely Defined Failure Scenarios

• Challenge: Insufficient attention to exception scenarios (e.g., failure responses and how many time the failure is allowed) can lead to vulnerabilities linked with brute force attacks.
• Solution: During API design, thoroughly define and implement robust exception/failure handling mechanisms for all possible failure scenarios, including limits on number of retries to prevent potential brute-force attacks.
• My Experience: “This is from one of the ecommerce implementations, where we were designing a sales journey for prospects/visitors. In the checkout process, we had a step to accept payment instrument (e.g. credit card) and validate it using a third-party service. While this seems straightforward, the catch was, if payment instrument is found invalid we would continue to give infinite number of chances for user to retry new payment instrument. The absence of limited retries exposed this API to potential brute-force attacks. Additionally, post couple of (random) failures, ideally system should have through a challenge to validate if it is a BOT or a human trying to launch an attack.”

Conclusion: Building a Secure API-Driven Future

These challenges underscore the importance of proactive and collaborative efforts to secure APIs. By implementing comprehensive security practices, employing a strategic approach to API design and governance, and fostering open communication between teams, we can navigate the ever-evolving API landscape and build a secure foundation for a thriving digital future. Remember, API security is a shared responsibility, and by working together, we can ensure the success of our API-driven endeavors.