When you think of disruption, the typical image is a tornado coming through and ripping things up, leaving towns leveled and nothing the same moving forward. But disruption can be slow and steady, incremental in the way everything you thought you knew has changed. Securing cloud environments was like that, initially trying to use existing security concepts and controls, which worked well enough. Until they didn’t and forced a re-evaluation of everything that we thought we knew about security. The changes were (and still are for many) challenging, but overall very positive.

We see the same type of disruption in how applications are built, deployed, and maintained within most organizations. Macro changes include the migration to cloud disrupting the tech stack, application design patterns bringing microservices to the forefront, and DevOps changing dev/release practices. As we’ve been slowly navigating this sea change, the common thread between these changes is an increasing reliance on application programming interfaces (APIs).

From a security standpoint, this new dependence on APIs changes the source of risk – it’s not just the front end under siege from traditional attacks and recon activities that map out backend processes. APIs have quickly emerged as the most attractive and least protected target within these new applications since they have access to critical data and services. Thus, we’ve decided to document this disruption and the impact on how you have to view application security moving forward.

We’re happy to introduce our latest blog series called Securing APIs: The New Application Attack Surface. In the series, we’ll go through how application architecture and the attack surface is changing, how application security needs to evolve to deal with these disruptions, and how to empower security in an environment where DevOps rules the roost. Because that is the way.

Let’s give thanks to Salt Security as the potential licensee of this blog series before we get started. As a refresher for those new around here, we don’t write sponsored papers. We publish research for practitioners that we may license to a vendor at the end of the process. That gives us the flexibility to go where our research takes us without undue influence. It’s a bit of a counter-intuitive model, but we’ve been doing it for 13 years at this point, and it works pretty well.

Application Architecture Today

As we get started, let’s go through how we see application architecture evolving. There isn’t one size fits all regarding architecture, and not all of these aspects may apply to your situation. But we’re pretty sure they will; it’s just a matter of time.

• Smaller: First, let’s highlight microservices. This approach breaks down traditional monolithic applications into a set of services weaved together through defined APIs. This approach adds modularity (yes, we used to call this reusability of components), flexibility and consistency since your developers don’t need to reinvent the wheel. It’s also heavily dependent on open source components that provide the base for many services.
• Faster: With the embrace of DevOps in many application teams, the objective is to eliminate the typical walls between Development and Ops (and security to a point), which creates shared accountability and focuses everyone on not just building but deploying and operating applications at higher velocity with better resilience. A key to making DevOps work is adding automation to manage the deployment process. The automation spans from code check-in, to testing (including security tests), and ultimately the deployment into production. How do you address the CI/CD (continuous integration/continuous deployment) pipeline and all the ancillary services orchestrated by the pipeline? Yup. Through APIs.
• Cloud-Native: The computing platform where the applications run also has evolved significantly. Given the requirements (as described above) of modularity, flexibility, and velocity, applications need to run in a more agile infrastructure. It may be public cloud, containerized, serverless, or some combination therein. When we say cloud-native, it can encompass any of the three, not just containers. But regardless, you interact with the computing platform via (drum roll, please) APIs. And increasingly, your infrastructure is described as code, which increases the application surface for security testing.

Another hallmark of modern application architecture is assembling applications, as opposed to building them. Using pre-built microservices to get started and building the components you need allows you to weave the application together without developing everything. This democratizes technology and allows business professionals to play a more prominent role in building the applications they need, potentially without IT interference. That’s a bit harsh but not too far from the truth.

And to reiterate, what do microservices, DevOps, and the cloud have in common? A reliance on APIs to integrate the components of the application stack. And that makes APIs a pretty sweet target for attackers.

API Attack Surface

As with most things security, protection starts with visibility. You’ve got options to enumerate the API environment, leveraging an inventory (such as a Swagger file repository) or via the discovery of APIs via scanning and network monitoring.

But visibility isn’t only for you. The problem is attackers can also use the same techniques to enumerate your API surface. Especially given that API requests and responses may travel over accessible networks, and Swagger files are accessible, providing an opportunity for an attacker to discover API parameters and potentially gain access to application data. We’ll go into a more detailed discussion of API visibility/discovery in the next post.

API Attacks

OWASP has done an excellent job of documenting standard API attacks in their list of OWASP API Top 10. These range from the simple, like randomly changing resource IDs to access other customer’s data (insecure direct object reference) or brute force attacks to identify weak links in API authentication. There are input attacks meant to cause API failures or traditional flaws like buffer overflows.

More complicated attacks involve gaming the application’s permission structure by invoking admin-level APIs without proper authorization or authentication. You can also see application defects like excessive data exposure when the application unnecessarily returns full data objects. Finally, you can have availability attacks, such as a denial of service against the API to overwhelm the system.

API attacks look a lot like other application attacks that we’ve seen for years. Attackers can go after the logic, the input, the availability, or the permission structure – and they do.

Traditional Defenses (are) Traditional

Since we are drawing analogies to traditional application security, we’ll need to consider how the traditional defenses would work against these kinds of attacks. By traditional defenses, we mean WAFs, API Gateways, and managed application security services. Let’s highlight some of the challenges of using these defenses within the context of an API attack.

• WAF: Within the context of new API attacks, think of a WAF as the equivalent of an email gateway trying to stop a web-based attack. It talks in a different language. The WAF can detect some API attacks (like an injection that look like application attacks), but its proxy architecture and limited rule sets present limitations in defending APIs.
• API Gateway: API gateways emerged to centralize API traffic for performance and reliability purposes. Security was mostly an after-thought, and similar to the WAF, the API gateway is rather limited in the security protection it offers. Malformed requests, brute force, and injection attacks are simple to handle. Yet, anything aiming to enumerate the API surface or exploit logic or excessive data flaws will go undetected.
• Managed Application Security Services: A new class of managed offerings has emerged that combines the WAF, DDoS, API gateway and adds some bot mitigation under one offering. They are typically offered by a CDN or cloud provider since they see the traffic anyway. Using a managed version of the previously mentioned solutions will address some operational issues but doesn’t address the underlying technologies’ limitations.

Additionally, tactics like application security testing also have a place in protecting APIs by scanning the Swagger files to find potential vulnerabilities and exposures. To be clear, we are not saying that these traditional protections are not relevant in this new API-centric world. They are necessary but not sufficient. It’s not a matter of either/or for these protections. The point we’ll make through the rest of the series is that you need to consider API security as an additional aspect of protecting your critical applications, and not just within existing application security tools and processes.

In the next post, we’ll dig into the approaches to protect the API layer and how those defenses complement the rest of your application security strategy.