Protecting Against the Top 10 Serverless Vulnerabilities


Serverless computing has been a game-changer for many organizations. It refers to an architecture in which code execution is managed entirely by a cloud provider, epitomized by the likes of ​AWS Lambda​, ​Azure Functions​, ​Google Cloud Functions and ​IBM Cloud Functions. Serverless services stand in contrast to the classic method of building applications and then deploying them on servers. The benefit of going serverless for a developer is not having to be concerned about the management, provisioning, and maintenance of servers when it comes to deploying their code. This can greatly speed up the deployment process, while decreasing cost.

But although adopting serverless technology comes with some big advantages, it’s not a magic bullet when it comes to solving all problems. Serverless computing still involves the execution of code, even if it does not run on a managed server. It means that code written in an insecure way remains vulnerable to the likes of application-level attacks — including Command/SQL Injection, Cross-Site Scripting (XSS), Denial of Service (DoS), and other attacks.

The Open Web Application Security Project (OWASP) Serverless Top 10 is a detailed report that aims to educate users about the inherent risks in common serverless application security vulnerabilities. It’s an essential document when it comes to serverless security, and the techniques that can be utilized to spot and protect against these potential weaknesses. 

Here are the top 10 threats:

#1. Injection

Injection attacks are some of the oldest attacks that are targeted at web applications. Unfortunately, they remain a problem for serverless computing. In an injection attack, an attacker “injects” an untrusted input, which gets processed as a command or query, and ultimately changes the execution of a program. In the cases of serverless applications, the possible attack surface increases. It could be used to delete or change records, and may even result in a cloud account takeover.

#2. Broken authentication

Most commonly due to poor design of access and identity controls, serverless architecture can make the problem with broken authentication more challenging than traditional architectures. It could result in sensitive data being leaked, as well as breaking a system’s flow of execution and business logic.

#3. Sensitive data exposure

Sensitive data is one of the biggest fears of individuals or organizations, regardless of whether they’re using serverless architecture or not. The kinds of attacks that can lead to sensitive data being exposed — such as man-in-the-middle (MitM) attacks or stealing readable data while it’s in transit — continue to apply to applications running serverless.

#4. XML External Entities (XXE)

XML External Entity attacks go after applications which parse an XML input. The results could include leaked data, Denial of Service (DoS), and more. 

#5. Broken access control

Attackers might go after over-privileged functions as a way to gain access to resources in an account. This may lead to data leakage from a database or cloud storage, loss of control over resources or even an entire account.

#6. Security misconfiguration

Bad actors could take advantage of this vulnerability to find misconfigured functions with low concurrency limits or long timeouts and utilize them to trigger a Denial of Service (DoS) attack. This vulnerability could also be used in a way that might allow attackers to leak sensitive information.

#7. Cross-Site Scripting (XSS)

XSS attacks let attackers inject client-side scripts into the web pages that are then viewed by other users. In a serverless version of this attack, the source of the stored attack is likely to be emails, cloud storage, logs, and other sources, rather than from databases or reflective inputs. Nonetheless, the impact of these attacks may be extremely nasty.

#8. Insecure Deserialization

This vulnerability involves untrusted data being utilized as a means to abuse the logic of a particular application. In a serverless environment, it could mean running arbitrary code that results in sensitive data being leaked or resource and/or account control.

#9. Using Components with Known Vulnerabilities

Serverless functions are typically small and used only for microservices, making use of dependencies and third party libraries. This opens up the risk of vulnerabilities in the supply chain. Not all vulnerabilities will be significant, of course, but some major data breaches have been the result of component vulnerabilities being exploited.

#10. Insufficient Logging and Monitoring

Serverless auditing can be tougher than with traditional applications. It can make it difficult to spot potential security, such as an attacker infecting application code, until it’s too late.

Protecting against the attacks

Fortunately, the OWASP Serverless Top 10 doesn’t just list problems with serverless architecture; it also offers advice on how to solve some of these problems — whether that’s reviewing third-party libraries for known vulnerabilities involving deserialization or implementing different types of access and identity controls requiring different types of authentication. 

For those who use serverless architectures, the smartest move may be to bring in the cybersecurity experts to help. They can provide tools that will embed themselves in serverless functions to defend against developing attack vectors. Experts can offer comprehensive visibility, alongside automated mitigation tools, and the like. 

By utilizing these weapons in your arsenal, you can get the most out of serverless architecture, without having to worry about the potential downsides.