Building a modern API security strategy: A five-part series — Overview

The Spring4Shell exploit was, really, quite elegant. 

The critical remote code execution (RCE) flaw wasn’t an application programming interface (API) vulnerability, but it was an autobinding vulnerability of the type that can easily apply to APIs. It tricked the Tomcat logger into writing a new JSP file that could do anything the attackers wanted: All they had to do was browse to it.

Spring4Shell is important because the vulnerability was nobody’s fault. Spring — the open-source application framework that provides infrastructure support for developing Java applications — had a good defense in place. So did the developers writing the code. It was simply an interaction between components that caused the problem to be so serious.

Spring4Shell is an example of how securing APIs is drastically different from securing applications. While APIs are just as hackable as traditional web apps, many are surprised to find that securing APIs isn’t the same as application security. You may well think that our current security tools are appropriate for APIs, but alas, they aren’t. Static Analysis Security Testing (SAST) and Dynamic Analysis Security Testing (DAST) — where the scanners lack visibility into just what, exactly, they’re scanning — were designed for web applications from the early 2000s, and they haven’t advanced much since then. 

Spring4Shell is just one example of why API security demands a modern approach — one that embeds instrumentation into the guts of code to analyze what’s happening in all components, including in all the libraries, the API server and platform components. When you think about API security, you need to think about problems that come from all of those sources, be they from code, libraries, platform frameworks or the interactions between those pieces. 

The five parts of API security

API security boils down to the five areas below. In this series, we’ll dive into one each week — starting next week — to show how a modern, integrated API security platform manages to accomplish what traditional API or application security can’t do: namely, to secure APIs from the inside out. 

• API inventory: You can’t secure what you don’t know. You need an inventory process.
• API security testing: You’ve got to write secure code, and that means finding unknown vulnerabilities in APIs, microservices and functions. After all, the OWASP Top 10 vulnerabilities are just as applicable with APIs as they are in traditional web apps. 
• Components: You have to secure your supply chain, including finding known vulnerabilities in active third-party libraries, frameworks and services.
• API protection: In order to protect production, you’ve got to identify probes and attacks on both known and unknown vulnerabilities and prevent exploits. 
• API access: Strong authentication and authorization on functions at the API level as well as at the data layer are crucial. 

Stay tuned: Next week, we’ll be looking at API inventory and why Contrast focuses on runtime inventory. The way we see it: Why bother with never-invoked, dead-weight code that’s just hitching a ride on your binaries?

Also, be sure to check out this discussion between Jeff Williams, Co-Founder & CTO, Contrast Security, and Melinda Marks, Senior Analyst, ESG Research, where they unravel: 

• What the future of API security holds for enterprises.
• What you need to know to secure your APIs.
• Strategies to stay ahead of the CI/CD lifecycle game.
• The path forward to building unified developer and security teams that can build secure APIs.