Meet the OWASP Top 10
Cybersecurity is an incredibly well-researched area, with security professionals constantly assessing the ever-changing software landscape, identifying emerging risks and distributing preventative measures and advice. While as a modern serverless engineer you must accept the responsibility you have in securing the applications you build, it is absolutely crucial that you combine your own efforts with deference to professional advice and utilization of the extensive research that is publicly available.
Identifying the threats to the security of your software is one task that you should not attempt alone. There are several threat categorization frameworks available that can help here, but let’s focus on the OWASP Top 10.
The Open Web Application Security Project, or OWASP for short, is a “non-profit foundation that works to improve the security of software.” It does this primarily through community-led, open source projects, tools, and research. The OWASP Foundation has repeatedly published a list of the 10 most prevalent and critical security risks to web applications since 2003. The latest version, published in 2021, provides the most up-to-date list of security risks (at the time of writing).
While a serverless application will differ in some ways from a typical web application, Table 4-1 interprets the OWASP Top 10 through a serverless lens. Note that the list is in descending order, with the most critical application security risk, as classified by OWASP, in the first position. We’ve added the “serverless risk level” column as an indicator of the associated risk specific to serverless applications.
Table 4-1. Top 10 serverless application security risks Threat category | Threat description | Mitigations | Serverless risk level |
Broken access control | Access control is the gatekeeper to your application and its resources and data. Controlling access to your resources and assets allows you to restrict users of your application so that they cannot act outside of their intended permissions. | API authentication and authorization.Least-privilege, per-resource IAM roles. | Medium |
Cryptographic failures | Weak or absent encryption of data, both in transit between components in your application and at rest in queues, buckets, and tables, is a major security risk. | Classify data being processed, stored, or transmitted.Identify sensitive data according to privacy laws, regulatory requirements, and business needs.Encrypt sensitive data as a minimum.Protect data in transit with HTTPS/TLS. | Medium |
Injection | Injection of malicious code into an application via user-supplied data is a popular attack vector. Common attacks include SQL and NoSQL injection. | Validate and sanitize external data received by all entry points to your application, e.g., API requests and inbound events. | High |
Insecure design | Implementing and operating an application that was not designed with security as a primary concern is risky, as it will be susceptible to gaps in the security posture. | Adopt a secure by design approach.Security must be considered during business requirements gathering and solution design and formalized via threat modeling. | Medium |
Security misconfiguration | Misconfigurations of encryption, access control, and computational constraints represent vulnerabilities that can be exploited by attackers. Unintended public access of S3 buckets is a very common root cause of cloud data breaches. Lambda functions with excessive timeouts can be exploited to cause a DoS attack. | Define a paved road to secure configuration of cloud resources for engineers.Keep application features, components, and dependencies to a minimum. | Medium |
Vulnerable and outdated components | Continued use of vulnerable, unsupported, or outdated software (operating systems, web servers, databases, etc.) makes your application susceptible to attacks that exploit known vulnerabilities. | Delegate infrastructure management and security patching to AWS by using fully managed serverless services. | Low |
Identification and authentication failures | These failures can permit unauthorized usage of APIs and integrated resources, like Lambda functions, S3 buckets, or DynamoDB tables. | Leverage an access management service to apply proper, fine-grained authentication and authorization for API gateways.Rely on AWS IAM for inter-service communication. | Medium |
Software and data integrity failures | The presence of vulnerabilities or exploits in third-party code is quickly becoming the most common risk to software applications. As application dependencies are bundled and executed with Lambda function code, they are granted the same permissions as your business logic. | Secure your software supply chain with automated dependency upgrades and other controls.Remove unused dependencies. | High |
Security logging and monitoring failures | Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. Without logging and monitoring, breaches cannot be detected or analyzed. Logs of applications and APIs are not monitored for suspicious activity. | Enable API Gateway execution and access logs.Use CloudTrail monitoring to identify and report abnormal behavior. | Medium |
Server-side request forgery (SSRF) | In AWS this primarily concerns a vulnerability with running web servers on EC2 instances. The most devastating example was the Capital One data breach in 2019. | Serverless applications utilizing API Gateway and Lambda will not generally be susceptible to SSRF attacks.Avoid accepting URLs in client inputs, always sanitize incoming request payloads, and never return raw HTTP responses to clients. | Low |
There are two further noteworthy security risks that are relevant to serverless applications:
Denial of service
This is a common attack where an API is constantly bombarded with bogus requests in order to disrupt the servicing of genuine requests. Public APIs will always face the possibility of DoS attacks. Your job is not always to completely prevent them, but to make them so tricky to execute that the deterrent alone becomes enough to secure the resources. Firewalls, rate limits, and resource throttle alarms (e.g., Lambda, DynamoDB) are all key measures to prevent DoS attacks.
Denial of wallet
This kind of attack is fairly unique to serverless applications, due to the pay-per-use pricing model and high scalability of managed services. Denial of wallet attacks target the constant execution of resources to accumulate a usage bill so high it will likely cause severe financial damage to the business.
Tip
Setting up budget alerts can help ensure you are alerted to denial of wallet attacks before they can escalate. See Chapter 9 for more details.
Now that you have an understanding of the common threats to a serverless application, next you will explore how to use the process of threat modeling to map these security risks to your applications.