How to stop your exposed API business logic from being breached
This article was originally published in The Hacker News
After more than 20 years in the making, now it’s official: APIs are everywhere. In a 2021 survey, 73% of enterprises reported that they already publish more than 50 APIs, and this number is constantly growing.
APIs have crucial roles to play in virtually every industry today, and their importance is increasing steadily, as they move to the forefront of business strategies. This comes as no surprise: APIs seamlessly connect disparate apps and devices, bringing business synergies and efficiencies never witnessed before.
However, APIs have vulnerabilities just like any other component of software. Adding to that, if they aren’t rigorously tested from a security standpoint, they can also introduce a whole new array of attack surfaces and expose you to unprecedented risks. If you wait until production to discover API vulnerabilities, you can incur substantial delays.
APIs are attractive to attackers, not just businesses
Keep in mind that APIs do more than simply connect your applications; they change the functionality in unpredictable ways. Many of the unique weaknesses that APIs may introduce are well known to hackers, who have developed different methods to attack your APIs in order to access the underlying data and functionality.
According to the OWASP API Top 10, it is not uncommon for legitimate, authenticated users to exploit the API by utilizing calls that appear legitimate but are actually intended to manipulate the API. These kinds of attacks, aiming to manipulate the business logic and exploit design flaws, are attractive to attackers.
You see, every API is unique and proprietary. As such, its software bugs and vulnerabilities are unique and “unknown” as well. The type of bugs that lead to attacks at the business logic or business process level are particularly challenging to identify as a defender.
Are you giving API security testing enough attention?
Shift-left security is already widely accepted in many organizations, allowing for continuous testing throughout development. API security testing, however, often falls through the cracks or is performed without a sufficient understanding of the risks involved. Why is that? Well, there is more than one reason:
- Existing application security testing tools are generic and aim at traditional web app vulnerabilities, and can’t effectively handle the business logic intricacies of an API.
- Because APIs don’t have a UI, it is common for companies to test web, app, and mobile separately – but not the API itself.
- Testing APIs can be manually intensive and is not scalable when you have hundreds of them.
- Relevant experience and expertise may be in short supply, as API testing is more complicated than other types of testing
- With legacy APIs, you might not know about the APIs already implemented or the documentation.
So, while shift-left security is already valued by many organizations in general, API security testing is too often left out of the DevSecOps big picture.
This is unfortunate since API vulnerabilities require longer to remediate than traditional application vulnerabilities – in a recent survey, 63% of respondents reported that it takes longer to remediate API vulnerabilities. This number is also likely to rise given applications’ rapid adoption of and dependence on APIs.
While most security leaders are aware of the importance of API security testing, just under half say they don’t yet have an API security testing solution fully integrated into their development pipeline.
*** This is a Security Bloggers Network syndicated blog from Imvision Blog authored by Omer Primor. Read the original post at: https://blog.imvision.ai/how-to-stop-your-exposed-api-business-logic-from-being-breached
