If applications were organic, application programming interfaces (APIs) would be the circulatory system: they’re the connective tissue that enables the lifeblood to flow between applications, carrying data within different contexts and across multiple channels. 

But APIs are just as hackable as web apps, as demonstrated by the many major data breaches enabled by unsecured APIs, including, for example, LinkedIn’s 2021 breach or Parler’s 2021 hacktivist archives.

APIs have become some of attackers’ favorite targets, given that it’s easy to intercept and modify the HTTP traffic being sent between, say, the mobile banking app on a cell phone and the bank’s mobile APIs. From there, malicious actors can pivot: once they reverse-engineer the service API, attackers can try to hijack other users’ accounts, find injection vulnerabilities, access other users' data and launch other common attacks.

This has to do with architecture: up until recently, monolithic, large applications handled access to specific data sources. In contrast, the modern web application is actually a conglomeration of interconnected APIs, microservices, web apps, frameworks, libraries and serverless functions, spread across multiple cloud and on-premise environments. Data access to many different applications has moved to APIs — not necessarily just across the enterprise, but even publicly, across the internet, externally exposed to users and partners. 

Exposing the enterprise’s soft underbelly

From a security perspective, that’s risky. APIs aren’t necessarily insecure, but modern web app architecture means that employees and cybersecurity teams have got to think about whether they are. There could be a far larger attack surface and many more clients able to access the data than what used to be buried deep inside a big, monolithic application.

These API attacks are difficult to detect with traditional technologies such as web application firewalls, which can only see network traffic. The same is true of API vulnerabilities, as Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST) technologies were designed for web applications from the early 2000s, and they haven’t advanced much since then. The complexity of modern API code, the frameworks that support them, and the complex interconnections between them is simply too much for static tools. Such tools produce loads of false positives, and they miss serious vulnerabilities.

It’s even harder for tools when they try to analyze APIs, given the complexity of looking at API traffic from the network perspective. Instead of just receiving a simple HTTP request, APIs requests contain some kind of payload — say, an XML document or a JSON document — if not something even harder to analyze, such as a serialized object.

Instead of these old-school security tools, security needs to work from inside the running API so that the analysis can see exactly how the apps are behaving and can measure that behavior in order to detect both vulnerabilities and attacks.

Unifying security and developers to build secure APIs

As it is, around 48% of developers say that they regularly push vulnerable code into production. This is a problem with the market, not with enterprise development teams. Business leaders can't blame developers for the pressures they’re under to release code.

Nor can they blame security. Manual penetration testing and code review can be helpful in testing API security, but they’re not only slow; they also require expertise. Such testing approaches may have issues when scaling.

Another approach to API security leverages Interactive Application Security Testing (IAST): a cybersecurity method that runs in the background during normal QA testing of APIs, without the need to change anything about how developers build, test and deploy code. Another key piece of the puzzle is Runtime Application Self-Protection (RASP), which prevents vulnerabilities from being exploited, even if one somehow makes its way into production in API code or an open-source library.

If business leaders want to stop playing the blame game and instead get development and security teams to work together to build more secure APIs, security teams need to enable them to build safer code.

Give developers the tools they need to efficiently fix issues in a way that’s most efficient, at a time when they can best learn from their mistakes and minimize security risk. Help security staff automate testing routines — that’s how to get security and development to work together on building secure APIs.