Securing Your Serverless Web Applications

Going Serverless

Let’s get one thing straight: A “serverless” web application IS still executed on a server.

So, technically it’s not “serverless”.

However, it is called “serverless” technology because your web app no longer needs to be permanently hosted on its own dedicated server, nor on a shared server.

Serverless technology is an example of an increasingly popular trend towards Function as a Service (FaaS). Put simply, a developer builds a piece of code. When it needs to be executed, an API or trigger sends the code to a cloud server where it runs.

That’s it.


Daniel Stori, ‘serverless economic impact’, Creative Commons

This allows developers to build and deploy web applications without the need to know in advance all the server capacity and infrastructure that will be required.

There are some significant benefits to going serverless including:

  • The ability to stop worrying about server management. The beauty about serverless technology is that you don’t need to configure or maintain any servers.
  • Unprecedented flexibility to scale up as required. As traffic to your web application increases, you can rapidly increase capacity.
  • Servers crashing and bringing down your entire web application are a thing of the past – assuming you have well written code!
  • Save a fortune by saying good-bye to excess capacity. When your code isn’t running, you don’t pay a cent. This can result in big savings. By only paying for the actual time your code is being executed on the server, you won’t be billed for any idle time. Typically serverless technology providers charge just when the code is running, down to the nearest 100-milliseconds.

For all these reasons, the trend towards serverless web applications is growing. Many cloud vendors, including AWS Lambda, Microsoft Azure and Google Cloud Platform, support it.

Best of all, by adopting the serverless model, you’re able to build and run applications without thinking about servers, allowing you to focus more time and energy on other priorities.


What are the downsides?

When it comes to securing your serverless web application, you still face the same vulnerabilities as with a traditional server-based application. However, there are some additional risks you need to consider.

Two of the most important considerations when going serverless are:

  1. API Security – Due to the fact that serverless web apps usually depend heavily on APIs to execute code or create the relevant trigger, ensuring those APIs are secure is a major concern.
  2. Lack of Control – Serverless web apps may be more susceptible because, compared to server-based apps, you have less control and there aren’t the range of security tools available. This makes ensuring you have quality code even more important.



Serverless apps work by transferring code and sensitive data via an API or a trigger to a server each time the code needs to execute.

Any security weaknesses in those APIs could result in you being more exposed to attack. You need to think carefully about having the right API security strategies in place to mitigate this threat. Apart from the risk of data breaches, vulnerable APIs could allow attackers to take control of your application.

With APIs integral to digital transformation strategies, many organisations are shifting from running a few APIs to now running hundreds, if not thousands of them. Having the capacity to detect malicious activity across so many APIs is a significant challenge. Our experience indicates that some of the most common attack vectors include broken authentication mechanisms and broken function-level authorisation flaws.

Furthermore, even if the API itself is secure, some inadvertently leak data while backing up files to a repository, such as GitHub, or expose information when interacted with in a manner that the developer did not anticipate.

The risks associated with APIs are exacerbated in a situation in which serverless resources are being automatically scaled-up to accommodate increased user demand. With automatic scaling, if you’re leaking data, you could start leaking data even faster.

That’s why organisations that adopt serverless web applications may be assuming greater risks than those that stick to server-based applications.  

At Shearwater, we recommend stricter controls around API usage to limit those risks.

Organisations should ensure they are maintaining an accurate inventory of all their APIs, in order to keep track of what’s running at any given time. In line with that, we also recommend that developers establish secure processes for the creation and deployment of new APIs.

Importantly, app developers should also review their authentication and authorisation mechanisms, as well as the processes by which API code is modified.



The flexibility afforded by serverless web apps is one of their great advantages. However, this could result in you forgoing a degree of control.

Serverless technology means practically anyone in your DevOps team can develop and execute code quickly. You need to ensure that adequate checks and balances are in place to review apps before they go live. Failure to have adequate controls in place could result in weak code, leaving you dangerously exposed.

Furthermore, there are still relatively few security tools available for this nascent technology, and the tools that are available usually don’t offer you the level of control you’d have with server-based apps.

When it comes to securing a serverless web application, you may be limited by the tools and features made available by the cloud platform provider you choose to use (e.g. AWS Lambda, Microsoft Azure or Google Cloud Platform).

Often, the security tools and features these providers supply are specific to their platform only. They are usually not compatible with other platforms. Such platform-specific security features often fall short of what’s really required: operating system security features and controls.

In addition to this, all too often we see that platform-specific security features made available by the big cloud vendors don’t meet the client’s specific requirements.

For example, if you’re developing a serverless web app that should only be accessible from specific IP addresses, and you’re looking to host it on AWS Lambda, you’ll face the problem that the AWS API Gateways can be reached from anywhere on the public internet. Furthermore, they can be accessed simply by using an API key, which many now consider offers insufficient security for APIs, given the volume of secure data they transmit.


How to stay safe?

All too often developers land in hot water because they’ve written code for a serverless environment and then forgotten about it. 

Due to the fact that ongoing work on a server isn’t required, it’s easy to lose track of the code that’s been written and is being executed by a cloud service provider.

Serverless technology isn’t “SET & FORGET”

To help developers who use serverless technology stay secure, OWASP (Open Web Application Security Project) recently launched a provisional list of the 10 most common vulnerabilities specifically faced by serverless web apps.

This initiative is recognition of the fact that serverless technology is increasingly popular and faces some unique security challenges. The list identifies the most common attack vectors, security weaknesses, and business ramifications of successful attacks on serverless applications. Importantly, OWASP focuses on prevention strategies.

OWASP Top 10 Serverless Vulnerabilities

Threat Type

Threat Gauge


Serverless applications tend to have larger attack surfaces than server-based applications. This could result in more injection attacks on various functions. The impact will depend upon the specific permissions granted to the attacked function. For example, if a function with high privileges which accesses cloud storage is attacked, the injected code could delete or upload corrupted data. If the function also has access to database tables, records could be deleted or inserted. It could even result in a cloud account takeover.

Broken Authentication

Broken authentication can allow an attacker to either capture or bypass the authentication controls used by a web application. This is usually caused by poor design of identity and access controls. With multiple serverless web apps running simultaneously in stateless containers, attackers will look for a forgotten vulnerable resource. If it can be accessed without authentication, this could result in sensitive data leaking, as well as the potential breaking of the system’s business logic and flow of execution.

Sensitive Data Exposure

Sensitive data exposure is a concern in serverless architecture, just as in any other architecture. Most of the methods used in traditional architecture, such as stealing keys, performing man-in-the-middle (MitM) attacks and stealing readable data at rest or in transit, still apply in a serverless environment. However, the data sources might be different. Instead of stealing data from a server, the attacker can target cloud storage and database tables. Storing sensitive data in plain text, or even using weak cryptography, should always be avoided.

XML External Entities (XXE)

An XML external entity injection (also known as XXE) is a vulnerability that allows an attacker to interfere with an application’s processing of XML data. XML is a mark-up language, much like HTML, that was designed to store and transport data. A successful XXE attack in a serverless application could lead to code and other sensitive files leaking from the environment.

Broken Access Controls

A serverless application can consist of hundreds of different microservices. Each will have different functions, resources, services and events. Together they create a complete system logic. The stateless nature of serverless architecture requires careful access control configuration for each of the resources. Attackers will target over-privileged functions in order to gain unauthorised access to resources in the account rather than having control over the environment.

Security Misconfiguration

In serverless architecture, each function or resource can be the weakest-link into the application. While the likelihood of gaining full control may be lower than in server-based apps, and the impact may be less (depending on the role), the increased number of entry points suggests a slightly higher risk when it comes to serverless technology, compared to traditional architecture. Misconfiguration could lead to sensitive information leakage or unauthorised access to cloud resources. Attackers will try to identify misconfigured functions with a long timeout or low concurrency limit in order to initiate a Denial of Service (DoS) attack.

Cross-Site Scripting (XSS)

Cross-Site scripting (XSS) attacks target browsers, which means attack vectors in a serverless environment are similar to a server-based environment. However, in a serverless environment, the difference is likely in the source of the attack. The source of traditional XSS attacks are usually databases or reflective inputs. In a serverless environment they could also originate from different sources like emails, cloud storage, logs, IoT, etc. Encoding all untrusted data before sending it to the client, as well as using known frameworks and headers, are essential to prevent XSS attacks.

Insecure Deserialisation

Dynamic languages like Python and NodeJS, together with the common use of JSON, a serialised data type, could make deserialisation attacks a little more common in the serverless world. As usual, the impact depends upon the application and the data it handles. Insecure deserialisation usually results in running arbitrary code that could eventually lead to data leakage and, in severe cases, even resource or account take-over.

Using Components with Known Vulnerabilities

This is one of the most widespread vulnerabilities when it comes to serverless web applications. Serverless functions are usually small and used for micro-services. To be able to execute the desired tasks, they make use of many dependencies. Developers may not be aware of all of them and may not be keeping them updated. Dependency scanners can help with this.

Insufficient Logging and Monitoring

Attackers rely on the lack of logging and monitoring to achieve their goals without being detected. Serverless auditing is more difficult than traditional-server auditing, because developers usually rely on the security tools supplied by the cloud vendor rather than using their own more suitable tools. This provides an opportunity for attackers. You should deploy auditing and monitoring mechanisms beyond those supplied by the cloud vendor to better identify security events.


In addition to these Top 10 serverless vulnerabilities, OWASP identifies some additional serverless security risks you should also consider:

Threat Type

Threat Gauge

Denial of Service (DoS)

The fact that each function is handled in a separate environment means that DoS attacks are not necessarily as great a risk in serverless technology. The fragmented nature of serverless apps means it will only affect those events coming into this specific environment without usually affecting subsequent events.

Denial of Wallet (DoW)

Automated scalability is one of the reasons to go serverless. It allows you to pay for the amount of server capacity you use to execute your app’s code and nothing more. Nevertheless, it comes with a risk that attackers can trigger resources (e.g. external APIs, public storage) upon their will and cause financial damage to your organisation.

Insecure Secret Management

It is always hard to securely manage all our secrets. However, secrets can usually be managed on a protected location in our backend. However, in a serverless environment, secrets are shared across resources in the account. Secrets like cryptography keys, API tokens, storage credentials and other sensitive settings are now shared more easily between functions and code, which could lead to sensitive data leakage that could be hard to mitigate.

Insecure Shared Space

Serverless environments are usually designed to be temporary. Once a serverless environment becomes redundant, there’s a risk that the application wrote some data into the user-space (e.g. /tmp) which could subsequently be accessed by an attacker.

Business Logic Attacks / Flow Manipulation

Business logic attacks may be the most complicated attacks to detect and usually have a high business impact. In a business logic attack, an attacker takes advantage of a flaw in the programming that manages the exchange of information between a user interface and an application’s supporting database. Microservices can be particularly vulnerable. While attackers can identify, constrain and manipulate flows in both traditional and serverless environments, the fact that microservices mostly execute in serverless environments means that careful design principles should be applied.


How Shearwater can help you?

When developing serverless web applications, it is essential to ensure you have secure APIs.

Shearwater are experts at API Penetration Testing.

Our team will scrutinise your APIs to identify and exploit potential vulnerabilities and weaknesses. This is a critical step in hardening your APIs to prevent them being exploited by malicious attackers.

We can also robustly interrogate your serverless web apps to identify any weaknesses.

This will give you the awareness you need to ensure you can make the most of the advantages that come from going serverless, without opening yourself up to additional risks.

Contact us  today to speak to our expert Pen Testers.