API-led data breaches are creating pandamonium for security teams. Why do we make it so easy for threat actors to exploit them?

When we picture the scene of a truly phenomenal heist, we might think of a film like Ocean’s Eleven, with everything meticulously planned, practiced, and executed flawlessly for a big payday. This certainly makes for an exciting action movie, but the reality of most criminal enterprises is following the path of least risk and resistance, and in the world of cybercrime, lax API security creates the perfect window of opportunity, often with a low barrier to entry.

This has been the case for years, and the problem is growing out of control. APIs are clever little snippets of code that provide seamless communication between applications, and according to research from NoName Security, enterprises run an average of 15,564 within their organization. That’s far too much to track without a plan, and the general lack of ownership surrounding API security has created the ultimate white elephant. 

Let’s explore why.

Poor authentication hygiene, poor coding patterns, poor security outcomes.

Some of the worst data breaches on record have been made possible through weak API access control. Back in 2018, Aadhaar, the world’s largest ID database, suffered a catastrophic breach thanks to the lax API security controls of a third-party site, exposing the sensitive information of more than 1.1 billion Indian citizens.

Despite more than five years passing since that incident, we continue to see countless large enterprises tripped up by the same problems and experiencing a similar devastating outcome, with giants like LinkedIn and T-Mobile being recent victims of API security bugs being exploited by bad actors. It is clear that no matter the resources at an organization’s disposal to move at the speed of digital innovation and demand, in general, the “secret sauce” to address common vulnerabilities remains conspicuously absent.

For me, the driving concern is the perpetual use of poor coding patterns, and the general lack of security awareness - especially around API access control and authentication - that seems to plague development cohorts all over the world. And it’s not their fault: we must be committed to their continual upskilling in security best practices, as it relates to their everyday work, and give them the time and tools to improve their code quality. Too often, security is pushed aside, and developers are not brought on the journey to play a role in solving the issues that they have control over, but they can be easy scapegoats when stretched, overworked security teams are looking for the weakest link. It seems 2023 is the year we stop passing the buck, and start sharing responsibility with clear expectations and enablement, especially among those with the hands in code-level tasks. 

Who is holding the API hot potato in your organization?

A recent study from Traceable revealed some alarming insights into the ways API security is managed within many organizations. 40% of organizations do not have a dedicated API security professional or team, and the perception of who ultimately owns API security varies wildly. 38% of respondents insist the CISO owns it, while 25% claim development and/or DevOps is responsible. Worryingly, 24% of respondents simply don’t know who or what department should manage API security matters day-to-day.

If ownership and responsibility for API security are hazy, or it’s a hot potato that seems to bounce between security personnel and developers, it’s time to draw a line in the sand and establish key roles and responsibilities. 

In my opinion, it can and should be a developer-owned issue, but do not leave them in the dark and expect them to find their way. Precision, relevant learning pathways should be made available, and those who step up should be compensated for their increased value as security-skilled developers. 

Privilege escalation is the ultimate goal (and we roll out the red carpet).

We have known for a long time that API access control exploits often turn into potent privilege escalation attacks, and this outcome is highly desired by the threat actor.

Put simply, the way in which we currently handle API security makes this potentially devastating incident easier than many other attack vectors, with the promise of a seriously valuable payoff. We shouldn’t be making it so easy, and one of the most straightforward solutions is to fix long-standing ownership issues for good, by enabling developers to tackle API security issues as second nature. Yes, it’s extra time, training, and responsibility, but the pros far outweigh the cons and improve the security posture of any organization.

What are you waiting for?