Securing APIs — It’s Different Than Securing Apps
I recently tuned into a CISO panel discussion and one of the panelists said something that struck me — “Application security today is less about the applications and more about the APIs.” On one side, that’s a perspective I take for granted, so I thought he was stating the obvious. On the other side, I realized that perspective is new to a lot of security leaders and worth a deeper dive to explain why application security today is less about the applications and more about the APIs.
For this post, I’ll focus the discussion on web and mobile applications and compare “traditional applications” that have little or no APIs with “API-based applications” that are heavily dependent on APIs.
Learn how app architecture and attack surfaces are changing, how app security needs to evolve, and how to empower security.
Download NowHow API-based apps differ from traditional apps
API-based and traditional applications differ in two key areas: where the processing is done, and where the application logic is exposed.
With a traditional application, the majority of the processing and application logic resides in the data center. As an example, a traditional application will receive a request form a client, query data from a database, and render the page in a web server before sending the rendered page back to the client. These applications can be protected with layers of security that include authentication, authorization, and encryption and tools such as firewalls and Web Application Firewalls (WAFs).
API-based applications expose much more of the application logic and data outside of the data center. As an example, a client will make a request over an API, the application will respond with raw data (often more than is needed), and the client is left to render the view. This model exposes not only more of the application logic externally but also more data.
Organizations still need to apply the protections used to secure traditional applications, but these tools and systems are not enough to protect API-based applications since the majority of the attack surface for API-based applications is exposed externally.
Security must also be different from APIs than for apps
APIs have their own set of vulnerabilities to consider, distinct from applications. In 2019, OWASP released the API Security Top 10 list of API threats, detailing the top threats to APIs. Five of the threats outlined don’t appear on the flagship Top 10 Web Application Security Risks, two have been deprioritized, and traditional application security tools address only a small fraction of the top 10 API threats.
Another challenge in securing APIs is that every API a company creates is unique, with unique logic and unique vulnerabilities. Attackers looking to find and exploit these vulnerabilities must probe each API uniquely as well — the signature-based approach traditional application security tools use to stop known attack patterns are useless in the face of such attacks.
API attacks run “low and slow,” as attackers perform reconnaissance to discover the structure of the API, understand the logic, and look for vulnerabilities to exploit. Reconnaissance takes time, and security tools operating as inline proxies will not see an attacker’s probing as the collective efforts of a single bad actor, because those systems, limited to inspecting each transaction in isolation, cannot see — much less paint for you — the bigger picture.
Organizations can customize many traditional security tools to define specifics about the application, but relying on customization still fails to meet the needs of securing APIs. First, even with perfect configuration, these tools cannot identify the subtle probing of attackers attempting to manipulate unique API logic. Second, customization is entirely impractical in API security because APIs change at the speed of modern CI/CD development practices. Security teams simply can’t keep customizations up to date to secure applications .
The right approach to API security
To protect API-based applications, you need to focus on protecting APIs themselves — finding them, understanding where they expose PII and other sensitive data, and identifying and stopping attacks at runtime. API security solutions must be able to learn the logic of each unique API, correlate the activity of an attacker probing those APIs, and block that attacker. This approach requires analysis of large amounts of data to gain the context needed to identify and stop attacks. Being conclusive about which anomalies are “bad” vs. simply a mistake or the result of a changed API also depends on that context and is essential for reducing false positives.
Here at Salt Security, we’ve been able to draw on the collective experience — otherwise known as attacks — of dozens of our customers to more finely tune into the behaviors attackers use to exploit APIs. Visit https://salt.security/demo/ to learn how Salt Security can protect your API-based applications.
