Cobalt Crowdsourced Application PentestCobalt Crowdsourced Application PentestCobalt Crowdsourced Application Pentest

Back to Main

Is Your Serverless App Secure?

Swaroop Yermalkar
Aug 7, 2019

In the past few months, I’ve hosted several sessions on serverless security for serverless developers and DevOps folks. What I’ve realized during these sessions is that there are quite a few inaccurate assumptions that developers are making.

Most of the developers I interacted with *assumed that *their serverless applications are secure by default because:

  1. There is no managed server

  2. The Serverless App uses HTTPS

  3. The Serverless Provider takes care of security

Is that really true? Just because the application doesn’t use a managed server, means its secure?

The answer to this is — No. Serverless applications impose similar risks as traditional web applications. As there is no managed server, it minimizes vulnerability management/patching of managed server part but rest risks are applicable.

Let’s understand the attack scenarios with 4 practical examples:

[Note: *All the below attacks are performed in the *test AWS account. Do not set up vulnerable apps/setups in prod AWS accounts.]

1. Information Gathering

The first step is knowing that the application you are accessing is serverless! While performing a pentest, check for default exceptions thrown by the application. In the below screenshot, you can see the default exception at */var/task *which is a location for the lambda functions at the server-side.

Improper Exception Handling in Serverless App

Another example could be fuzzing endpoints through burp suite/proxy tool as below:

Improper Exception Handling in Serverless App

The above screenshots throw default exceptions and give us details about serverless / lambda service at server-side. Next step is exploiting it:

2. Reverse Engineering Lambda Function

The server-side code / Lambda function could be accessed from the end-user by exploiting the injection attacks at the application layer.

Below is one example of accessing Lambda Function from the end-user side:

Dumping Lambda Code using Command Injection Vulnerability in Serverless App

3. Broken Authentication

Have you ever found a lack of rate-limiting protection in a web application? If yes, then you might observe the same in a serverless application as well!

The below screenshot shows a successful brute force attack on a serverless app endpoint for credit card numbers:

4. Listing IAM Users / Compromising AWS Account

Using a command injection vulnerability, it’s also possible to dump environment variables as shown below:

Dumping Environment Variables in Serverless App

Once you get the Session Token, Secret Access Key, and Access Key, you can configure them in your system using ‘export’ command and then use *AWS CLI *(AWS Command Line Interface) to make AWS calls.

Now you can use #aws sts get-caller-identity to get role information. If roles are not properly defined or have extra permissions, then you can try out other commands like #aws iam list-users

Listing IAM Users

The demonstrated attacks above are just a high-level overview of serverless exploitation. There could be multiple attack vectors and entry points based on the type of application.


Just because it is a serverless application doesn’t mean that it is secure! If you take a look at **OWASP Serverless Top 10, **you will notice that all attacks applicable to traditional web applications are also applicable to the serverless apps.

So it's important to follow security best practices while developing a serverless application and make sure that your app is regularly reviewed by security teams.


  1. OWASP ServerlessGoat

  2. A Damn Vulnerable Serverless Application