Australian application teams are now wondering whether their APIs overshare

The recent high-profile exploitation of a public-facing API at an Australian company highlighted a risk many had warned was coming.

The world has become increasingly reliant on software to make everything work, and application programming interfaces (APIs) play a key role in that. Whether seeking a weather update, participating in an online event, collaborating with colleagues, or engaging in a telehealth consultation, APIs enable software components to talk to each other in the background to both make user requests and respond to them.

As a result, APIs have exploded in popularity as the default way to connect or otherwise communicate with applications, such as to query information held by enterprise systems. The number of companies working with public APIs almost doubled between 2019 and 2022, while the use of other API types - internal, private or third-party - now exceeds 90% in all cases.

API management needs a critical shift

As API sprawl and usage grows, management of this vast field of connections is not keeping pace. Gartner predicts that "by 2025, less than 50% of enterprise APIs will be managed, as explosive growth in APIs surpasses the capabilities of API management tools." As the world becomes API-centric, that lack of management will create security challenges.

This is already evident: Gartner predicted last year that API attacks would become the most frequent attack vector in 2022, "causing data breaches for enterprise web applications." On this, they were correct.

A publicly exposed API is widely believed to be the cause of at least one of the major attacks on Australian enterprises in the back half of 2022, attacks that have collectively driven significant policy reform from the government and reviews of cybersecurity posture on the part of other Australian enterprises.

And Australia isn't alone. Worldwide, around three-quarters of enterprises reported experiencing an API security incident in the last year. In a similar proportion of companies, cybersecurity professionals "did not have a complete API inventory or know which APIs returned sensitive data". Moreover, for 62% of organisations, one-third or more of APIs are undocumented.

Coupling this with the fact that "only 11% of respondents test APIs for signs of abuse in real-time", there are substantial danger signs that APIs can be used and abused to leak data and that very few organisations would pick up the problem in a timely manner before it ballooned into something far more damaging.

The key is training supported by an architectural rethink

By design, APIs open the floodgates for communication between apps. As a result, it's possible to have too much talking between APIs, which will overshare "too much information" if that is made permissible.

In addition, when the risk-mitigation measures for API access control are lax, APIs will reveal too much information or - worse - expose themselves through a vulnerable app backdoor. Too often, developers over-permission APIs for functions so they don't have to keep changing access rights with every program build. However, attackers are well aware that this is happening, so they seek to breach APIs and use their powerful permissions to infiltrate networks.

To effectively mitigate against these challenges and attack risks, organisations need to train their developers on "security first" while subjecting APIs to least-privilege Zero Trust policies.

How to strengthen API security

First, organisations should work to upskill developers to cultivate a "security first" culture. Security first and other so-called 'shift-left' approaches seem to bring a security mindset into everything a developer produces. It's critical to educate developers about the nuances that differentiate a poor coding pattern from a good one to help them focus on building safe software from the start.

In addition, when security teams strengthen their communications and relationships with developers, those developers learn how to use the right tools for protection and even maximise their value. Hands-on/person-to-person training is essential here. Computer-based training by itself comes with too many limitations, often lacking the ability to verify the security skills of participants. Organisations and security teams need assurance that the knowledge has stuck and is being implemented correctly as part of the software development lifecycle.

Practising real-life scenarios can assist in this regard. Developers benefit the most by experiencing the real-world scenarios and consequences of broken access control – it's the most potent way to both verify and improve skills, and all training programs must include this if they are to be successful.

Outside of specific training, security and development teams are advised to extend the concept of Zero Trust to APIs. We typically consider Zero Trust in terms of user access - controlling how people authenticate to the corporate network and what they are permitted to do. Organisations should also apply Zero Trust to APIs to eliminate over-permissioning and enforce role-based controls. If an API is supposed to perform a specific function, then security teams must work with developers to restrict permissions to solely that function.

In further incorporating Zero Trust, security and/or developer teams are advised to limit the calls APIs are allowed to make, so these calls are strictly conducted based on context-centred requests. Subsequently, attackers will encounter difficulties in modifying them for criminal purposes.

The road forward

APIs are going to remain a vital part of today's interconnected world. Their ability to request and receive data from other sources means they underpin a significant portion of online transactions. As API security shifts, it's crucial for developers to understand their role in keeping APIs secure.