Cloud application security vulnerabilities: A comprehensive guide

Cloud-native application security continues to rise in importance as more organizations incorporate cloud architectures. Understanding cloud application security vulnerabilities is essential for defending against serverless security vulnerabilities, cloud API vulnerabilities and microservices security issues that threaten countless IT departments. 

Fortunately, by understanding the nature of cloud app security risks, as well as how to mitigate them, you can drastically reduce your risk, improving cloud supply chain security. To help you eliminate SaaS security vulnerabilities and other cloud application threats, here’s a breakdown of how cloud architectures map to the OWASP frameworks, some common vulnerabilities and how to mitigate them. We’ll also discuss ways to keep your cloud-native code and architecture secure. 

Editor’s note: Defending cloud workloads starts with understanding how they’re built and function. Take our free AWS workshop to learn by doing: Build and deploy your first cloud infrastructure. 

View Free Course

Mapping cloud architectures to OWASP frameworks 

Categorizing threats based on OWASP cloud application risks makes it easier to build a strategy molded around OWASP recommendations. The following three OWASP frameworks align directly with modern cloud architectures: 

• OWASP API Security Top 10. This focuses on vulnerabilities often presented by APIs. These apply to microservices, containerized services and serverless endpoints. 

• OWASP Serverless Top 10 (Interpretation). This is essentially a “serverless top 10” designed to address common vulnerabilities in these environments, specifically those that can impact functions, managed infrastructure and event triggers. 

• OWASP Cloud-Native Application Security Top 10. These focus on containerized and orchestration environments, as well as microservices and infrastructure-as-code ecosystems. 

Once you map vulnerabilities to these frameworks, you streamline the process of exposing and categorizing each potential threat. This can serve as the foundation for defeating cloud application security vulnerabilities.

Common vulnerabilities and how they’re exploited 

Cloud workload protection starts with identifying the vulnerabilities that may exist in your environment because this paves the way for shrinking your attack surface. While a comprehensive list of all possible vulnerabilities would depend on your infrastructure and workloads, here are some common examples. 

Container escape 

A container escape, also known as a runtime breakout, is a vulnerability in a container runtime. It allows an attacker to get outside, or “escape,” the container and access files or directories outside the container. 

Container escape example 

An attacker may deploy a malicious container runtime in a Kubernetes cluster. The runtime enables the attacker to access the host’s root volume. At that point, the hackers can move laterally, impacting a range of workloads across the system. 

How to mitigate the risks of container escape attacks 

Mitigating container escape attacks starts with enforcing principles of least privilege, making sure only those who absolutely need access to containers are allowed to work with them. This may also involve going beyond merely restricting access to each container’s programming. It could include restricting the number of people who even get to use the applicable builds. 

In addition, to address cloud computing attack vectors, you can regularly patch container runtimes. Check Common Vulnerabilities and Exposures (CVEs) for corrupted runtimes that you may have installed. Then patch them by: 

• Grabbing an updated runtime using a sudo command that pulls it from the vendor’s package manager 

• Replacing the binary directly using a secure version from a repository, such as GitHub. 

Important note: You may want to include container runtime updates in your internal governance protocols. This way, you and your team can keep them up to date whether or not a CVE gets released.

Serverless function denial-of-service attack 

Whether you call this kind of assault a serverless function “resource exhaustion” or “disk fill,” it amounts to the same thing: an attempt to cripple a serverless function by uploading many large files. Once the serverless runtime gets overwhelmed with malicious uploads, it either fails or has to throttle its responses. 

As a result, the runtime itself fails to operate within specifications. Also, other functions that share the same data infrastructure can either fail or have their performances degraded. 

Serverless function DoS attack example 

CVE-2024-24752 is a good example of how attackers can levy what amounts to a DoS attack on a serverless runtime. This vulnerability affects the Bref PHP serverless framework running on AWS Lambda. An attacker can create several temporary files that don’t get removed. Soon, the disk used by the Lambda environment will fill up. Then all processes using this disk either fail or have to significantly throttle their performance. 

How to prevent serverless function DoS attacks 

There are a number of ways to stop these attacks before they happen, such as: 

• Periodically clean up temporary files. An attacker may try to evade detection by firewalls by gradually uploading temporary files over a few weeks. By cleaning up temporary files, you can both detect abnormal file uploads and thwart a hacker’s DoS strategy. 

• Use your cloud provider’s resource limitations. Your cloud provider likely has tools that can limit the amount of memory or disk space each request consumes. These can stop malicious uploads that consume resources in excess of specified thresholds. 

• Set up a monitoring system that checks disk space usage or error rates. If your disk space gets consumed by malicious data, your monitoring system will trigger an alert, and you can investigate the uploading activity. 

• Set quotas to control request size and the number of uploads per function. While this could also impact legitimate requests, it could also prevent an attacker from executing an exploit, especially if they’re trying to overload your storage over a short period of time. 

Image with known vulnerabilities 

This occurs when a microservice container has a base image with dangerous content, typically a library that has already been addressed by an existing CVE. When someone in the development department builds a microservice container, they fail to scan the library it uses for potential threats. This results in a vulnerability that’s relatively easy for a hacker to exploit.

Examples of how known vulnerability image exploitations work 

Hypothetically, someone could build a Docker container that introduces the CVE-2019-5736 vulnerability. This would pave the way for an attacker to gain control of the container via an image they have already exploited. 

Similarly, when working with Docker Desktop, someone could inadvertently introduce the CVE-2025-9074 threat. This could grant an attacker the ability to issue privileged commands to the engine API, allowing them to perform a range of malicious actions. For instance, they could control other containers or build new ones. 

How to prevent the exploitation of known vulnerabilities 

There are a number of preventative measures you can take to avoid these kinds of attacks, such as: 

• Enforce image scanning. Scan all base and runtime images for known vulnerabilities prior to production. 

• Maintain a software bill of materials (SBOM) for your dependencies. An SBOM is a machine-readable inventory of software components. It makes it easier to identify problematic images because it includes all images associated with each build. It also provides a list of known vulnerabilities associated with each component, which you can use to cross-check for issues. 

• Remove unused packages from all containers. This reduces the risk of a vulnerability introduced by a package you’re not even using. 

• Use only trusted registries. A trusted registry hosts only scanned, signed and verified images. 

Misconfiguring the identity and access management (IAM) of serverless functions 

An IAM misconfiguration is an easy target for an attacker, and this may occur when someone establishes a role that grants broad permissions instead of merely those the function needs. This by itself typically doesn’t result in an attack. An attacker would gain control of the over-privileged function via a different vulnerability (such as a compromised image) and then use their control to attack other areas of the system.

An example of a serverless IAM exploit 

In an Azure environment, you can assign a managed identity to an Azure function app. This gives it the ability to authenticate other Azure services without using keys or other stored credentials. With Azure role-based access control (RBAC), the managed identity can also have roles and permissions. 

For instance, it could be a user access administrator or own a resource group. 

If a hacker were to attack an overprivileged managed identity using code injection or another exploit, they could exploit its excess privileges and grant access to a compromised user account — one controlled by the attacker.

How to avoid attacks that use over-permissioned serverless functions 

One of the most effective ways to prevent attacks on overprivileged serverless functions is to make it a practice to grant only the minimum roles needed for each function. This may involve taking a little more time to set up each function, but it can go a long way toward shrinking your attack surface. 

In the same vein, you should only assign roles at the resource level, instead of at the subscription level. In this way, your role assignment process hinges on the necessary resources rather than on processes that may or may not actually need access. 

You can also regularly audit role assignments for all of your functions. Even if you use principles of least privilege, the minimum number of role assignments can change as your infrastructure evolves. An audit can easily identify overprivileged functions.

Tools for scanning for cloud security vulnerabilities 

Scanning your environment is a key element of cloud workload protection and container application security because it can identify issues before they result in breaches. Cloud security testing often relies on scanning to identify issues. 

As part of serverless function security, for example, you can use a scanning tool to examine the contents of a function and determine if it presents a vulnerability before you put it into production. 

The same holds true for your API gateway security program. Instead of manually checking all API-related code, you can use a scanning tool to surface issues automatically. 

Some of the top options for scanning cloud environments for security vulnerabilities include: 

• Static Application Security Testing (SAST) tools. You use these to analyze source code before runtime to identify security flaws. 

• Dynamic Application Security Testing (DAST). DAST is a form of black-box testing that checks a running app or API for runtime problems, such as signs of a code injection attack. 

• Software composition analysis or software bill of materials analysis (SCA or SBOM). Tools that analyze software compositions or bills of materials can check all of your dependencies, libraries and container images for CVEs. 

• Infrastructure as code (IaC) scanning. IaC scanning tools analyze your infrastructure as code for misconfigurations such as containers with excess privileges. 

How to keep your cloud-native code and architecture secure 

Although you can find ways to minimize cloud vulnerabilities above, here’s a condensed list of things to keep top of mind while building your infrastructure: 

• Use principles of least privilege and minimal access. For example, if a service has access to a database, grant it access only to the schema it uses for its own operations, not to other parts of the database. 

• Use only safe libraries. To do this, you can continually scan and update your dependencies to make sure they don’t contain compromised or malicious libraries. 

• Minimize each component’s dependencies. Only connect a component to a dependency if it needs it in the short term. Over-assigning dependencies to speed up future development, for instance, can unnecessarily expand your attack surface. 

• Encrypt all secrets and credentials while at rest. In this way, even if an attacker penetrates your system, they can’t use the credentials or secrets they find. 

• Monitor error rates, latency and abnormal patterns. For instance, if there are many failed authorization attempts over a short period of time, you should be able to detect this. Or, for runtime application protection, your latency may exceed a preset threshold, which your monitoring system would then flag. 

• Use cloud application firewalls. A cloud app firewall can detect and stop bots, cross-site scripting, SQL injection, and other types of attacks, making it a good addition to hygienic development practices. 

The cloud app security mindset 

Cloud-native app security is as much a state of mind as it is a collection of techniques and tools. It begins with proactively hunting risk, then mitigating it throughout the dev lifecycle. Every container, API, microservice and serverless function should be under constant scrutiny. A good place to start is the OWASP frameworks mentioned earlier. These make it easier to structure and formalize your vulnerability mitigation system. 

Cloud-native app security is just one of the factors driving modern cybersecurity. You can see a comprehensive list of the latest trends and certifications with Infosec’s Emerging trends infographic.