APIs have taken over, and that is not an exaggeration. The proof lies in the pudding (numbers):
Thanks to their ability to interconnect various apps, devices, and platforms, APIs have transformed product features, business offerings, and strategies (both technical and business-end). It is not a stretch to say that APIs are crucial in any industry that seeks a digital presence, be it on the public internet or their own isolated networks.
However, as with other technologies, APIs add vulnerabilities like all other software components in existence. Untested or inadequately tested APIs present another point of attack for hackers and malicious individuals. API security disclosures are almost guaranteed to invite infiltration attempts and can harm an organization’s products, internal tech stack, communications, or network efficiency.
By connecting applications, APIs can alter how they function. This may create specific vulnerabilities that API-focused hackers know of and invite them to attack said APIs to access their support data and functions.
The OWASP API Top 10 List states that insufficient authentication or missing authorization checks in API endpoints can allow malicious individuals to access sensitive data they are not authorized to. Further, by invoking APIs in a distinct order than built, they may be able to access functionality unintended for them, i.e., gain control of the application business logic – a hacker’s dream.
Since every proprietary API is unique, so are its vulnerabilities. Protecting its business logic adds a layer of difficulty for security mechanisms when it comes to defending against them. Let’s understand this with a simple example. Below is an example of a BOLA attack scenario against a famous social network in 2019:
As you see from this example, a group of two APIs and two objects (highlighted) were involved in the breach. The two APIs were chained/connected. Individually each of the API calls is benign. However, the change of object value while calling the second API in the malicious scenario results in the attack. If the second API implementation doesn’t do sufficient security checks, it will result in unauthorized access, breaching the logic built across the two APIs.
Current generation products can’t protect against such an attack due to a variety of reasons. First, their architecture limits them to look at every single network session in silos. They don’t understand application behavior or context. Second, they are mostly based on signature while one cannot write a signature to protect the above attempt. Third and a very important point, these attacks are extremely easy to carry out and don’t require deep knowledge of computer systems or network stacks, thereby attracting newbies into attacking APIs.
Finding and blocking such API attacks require building a deep understanding of the application behavior and user context that current generation security products lack.
While shift-left testing has gained wide acceptance in companies, API security is yet to become a fixture in all testing pipelines. Even when it is performed, security test cases are minimal, and the focus is on functional aspects.
A few reasons for this disparity are:
Another reason for such issues to exist aplenty is the limitations of API testing tools for shift-left:
Commonly, modern application security testing comprises two major approaches: static security testing and dynamic security testing.
Static security testing (SAST) uses the white-box tactic by looking into code for misconfigurations, hard-coding of keys or tokens, common vulnerabilities, etc. This entails examining design, code, and architecture as well as data paths.
Dynamic security testing (DAST) leveraged black box testing principles, with test cases built to monitor applications in various real-world user scenarios. It does not require knowledge of an app’s internal mechanisms.
Keeping in mind, API exploits are complex business logic exploits, in the case of APIs, there’s a strong debate as to which approach works best to test APIs. To prevent business logic exploits, a tool needs to build a complete understanding of the application behavior and user context. However current generation SAST & DAST tools don’t have the necessary architecture to baseline application behavior and build the required context. Hence benefits of both static and dynamic testing are minuscule for APIs. API testing needs to be approached by first building an understanding of the Application business logic.
Leaving API testing, especially security testing out of the shift-left picture leads to major gaps in the security coverage of APIs. The rapid adoption and implementation of APIs also mean that there will be more security gaps and vulnerabilities and organizations will seldom have the bandwidth to address issues in code already built.
By now it’s clear that APIs must be secured at multiple junctures across their life cycles. This requires meticulous streamlining of API Security Controls. Essentially, the engineering and security teams need a platform covering the entire life cycle of APIs and not point-products – a platform that can understand the application behavior and its business logic workflows, have comprehensive API visibility in real-time, is able to test APIs’ business logic workflows in addition to runtime monitoring and protection.
A business logic-first security approach to APIs is needed that introduces greater maturity into the organization’s API ecosystem and enhances the overall potency of its defensive processes and apparatus.
AppSentinels is a comprehensive next-generation full-lifecycle API security platform that leverages AI/ML to prevent advanced business-logic API attacks. Our deep learning models detect attackers early in the attack cycle and block them, guarding apps against data theft, breaches, and fraudulent invasions.
The platform discovers all APIs in real-time, provides a catalog of APIs as well as the PII/Sensitive data flow occurring via those APIs, and finally, risk score against the APIs.
Additionally, the platform offers business logic testing of API workflows that can be integrated with an organization’s CI/CD cycle to help organizations adopt a proactive approach to API security.
There’s far more than AppSentinels can do to protect your API architecture, and we’d be delighted to show you exactly how. Simply schedule a demo for an expert-led product walk-through.
