The Case for Integrated App and API Security Strategies
It is evident that app and API security have become more specialized. APIs are no longer just URI-based entry points into an application. APIs have grown up and become a separate entity with their own security needs.
Most of these security needs relate to the nature of API interactions. Namely, APIs need to be authorized on a per-transaction basis. This is markedly different than apps, which generally apply authorization on a per-session basis.
The rate of interaction, too, is higher for APIs, as are a number of other characteristics that pose especial challenges for securing APIs.
| App | API | |
|---|---|---|
| Message format fluency | HTML, JSON, XML | ProtoBuf, JSON, GraphQL, binary, XML, data formats |
| Interactions | Static, infrequent change | Dynamic, frequent change |
| Data | Structured, transactional | Un/structured, streaming, and transactional |
| User | Human | Software, human |
| User-agent | Browsers, apps | Software, device, scripts, apps, browsers |
| Authentication | Session-based | Transaction-based (more ZT like) |
| Protocol fluency | HTTP/S, QUIC | gRPC, WebSockets, HTTP/S, QUIC |
A comparison of apps and APIs illustrates differences that have caused a divergence in security needs.
That said, there are security risks common to both apps and APIs that bear consideration when implementing security solutions. For example, the recently updated 2023 API Security Top 10 clearly shows a subset of risks that are shared with applications:
- Weak authentication/authorization controls
- Misconfiguration
- Business logic abuse (credential stuffing, account takeover)
- Server-side request forgery (SSRF)
In addition to these risks, there continues to be a substantial number of attacks targeting availability. That is, DDoS attacks that are common to both apps and APIs, as they generally share the same dependencies on TCP and HTTP, both of which are subject to a variety of attacks designed to disrupt access and availability.
One approach to addressing the challenges of securing apps, APIs, and the infrastructure that support them is to deploy multiple solutions. Bot and fraud defense, DDoS protection, app security and API security. While this certainly addresses the security challenges, it introduces operational challenges and makes more complex many security-related tasks such as policy change management and reacting to threats that impact both apps and APIs. Complexity is not only the enemy of security, but also the enemy of speed.
The speed with which one can react to emerging threats is a top driver for the adoption of Security as a Service according to our annual research. Each solution requiring a patch, update, or the deployment of a new policy to mitigate an emerging threat adds time and increases the possibility of a misconfiguration or mistake. Thus, the time to mitigate a threat increases with complexity—especially if an organization is operating in multiple environments (hybrid IT) and leverages per-environment security solutions. I’m not doing the math to determine if that’s a linear or exponential increase because, honestly, anything that increases the time to respond to an imminent threat is not a good thing.
That’s why a better approach is to combine solutions, thus sharing operational and security management for functions designed to combat threats while allowing for specific security policies to address those protocols and payloads unique to apps and APIs.
This leads to an integrated application and API security strategy, in which common functions are shared with increasing granularity and specificity applied closer to the app or API. Bots are bots, after all, and their impact on the quality of data, cost of delivery, and risk profile for apps and APIs are a shared concern. DDoS is DDoS. Operating twice as many services to address the same problem is inefficient across every measure of the metric.
An integrated application and API security strategy makes good operational, financial, and architectural sense.