The adoption of application programming interfaces (APIs), has increased significantly over the last few years.  In many ways, APIs can be likened to the backbone of the Internet, as they have become a key to enabling digital transformation, and facilitating the exchange of data and information between applications, containers, and microservices. 

And while this radically improves customer experience, it also introduces a host of new risks into the environment. At first, the majority of companies either used APIs within a secure private network or accessed them through secure communications channels. However, a growing number of organisations have started to use APIs to open up access to internal applications, and data to a host of third-party partners, customers, and more. 

Unfortunately, there isn’t a governance process or technology today that has the ability to identify a technical risk in this situation, and bad actors are well aware of this. APIs operate below layer seven, which is the top layer of data processing that happens just below the surface, or behind the scenes of the software applications that users interact with. 

Most businesses don’t understand the threat vector that is brought about by having APIs in their environment. While they understand supply chain threats, they need to realise that much like supply chains, the APIs that connect enterprise applications and data to the Internet face the same risks and vulnerabilities that regular Web applications do, and need to be secured with the same vigour. 

After all, APIs are valuable targets for attackers, as they are conduits for fraudsters to access huge amounts of confidential data, such as customer information or proprietary business information. Moreover, APIs can be likened to a map for hackers, revealing where all the internal objects and database structures that can be exploited are situated. 

The number of vulnerabilities that threat actors can employ to exploit APIs is also increasing, thanks to insecure development practices. APIs are often released into production more quickly than security teams can thoroughly vet and catalogue them. In certain instances, security practitioners lack full visibility into all the APIs that are developed and released, making securing them impossible. 

Insecure development practices could include publishing APIs that have not been authorised and approved by the security team. This leads to shadow APIs that the security team cannot see, and therefore cannot secure. Unfortunately, these shadow APIs are still able to access the same sensitive data that their secured counterparts can.  

Similarly, APIs that are not properly decommissioned are practically a gift for attackers as these again are out of sight of security teams, and can be likened to putting electric fencing in, yet leaving the security gate open. A determined adversary could gain access with little effort, and use that access to carry out a range of attacks, and security teams would be none the wiser. 

This year, we predict that APIs will become an even more popular target for attackers. They will use bots to conduct scraping attacks or automated bot threats in which bad actors collect data from a target’s systems for malicious purposes. Vulnerable API endpoints often connect directly to the company’s database, and by using automated threats, hackers can target weaknesses relentlessly to get their hands on company data.

To address this surge in API threats, security teams must collaborate with developers to forge better relationships,  and ensure security is embedded into the development lifecycle from the ground up. They need to work as a team to create a strategy that ensures API security, and one that finds the balance between security and visibility on the one side, and speed and ease of use on the other.