Skip to content

OWASP Serverless Top 10

TAL MELAMED

AppSecOWASP Foundation29 minIntermediateOpen on YouTube ↗

TAL MELAMED explores OWASP Serverless Top 10.

Summary

### Overview In this talk, Tal Melamed, Head of Security Research at Protego Labs, introduces the OWASP Serverless Top 10 project. The project provides a serverless-tailored interpretation of the traditional OWASP Top 10 application security risks. Melamed explains that while serverless architectures (such as AWS Lambda, Azure Functions, and Google Cloud Functions) shift infrastructure management to cloud providers, they also introduce unique security dynamics because code execution is triggered by diverse cloud events rather than traditional API or network perimeters.

### Key Topics - **Nature of Serverless Computing**: Compute power executes inside ephemeral, stateless cloud containers that automatically spin up, execute code, and terminate. Execution environments are generally read-only aside from the `/tmp` scratch directory. - **Shift in Attack Surface**: Traditional perimeters like network firewalls are absent. Serverless security is strictly code- and application-centric (AppSec), driven by event sources rather than purely HTTP/API endpoints. - **OWASP Serverless Top 10 Mapping**: Adaptation of standard web vulnerabilities (injection, broken authentication, sensitive data exposure, XXE, broken access control, security misconfigurations, XSS, deserialization, vulnerable dependencies, and insufficient logging/monitoring) to serverless paradigms.

### Technical Details - **Event Injections & RCE Realities**: Because standard servers and persistent shells are absent, traditional remote code execution (RCE) or OS hijacking does not function normally. Instead, attackers exploit event injection (via sources like MQTT, cloud storage events, or emails) to execute child processes, write to `/tmp`, archive source code, or exfiltrate backend application files via tunnels. - **Broken Authentication Across Triggers**: While many teams secure API Gateways, roughly 30% of customer traffic enters through non-API triggers (such as AWS SES emails, cloud commit events, database changes, or IoT feeds). If functions assume internal triggers are trusted, attackers can bypass authentication by directly spoofing or generating triggering events. - **Function Keys & Sensitive Data Exposure**: Sensitive application data is frequently written to the writable `/tmp` directory. Furthermore, cloud function environments expose session tokens, access keys, and environment variables (such as AWS credentials) via process environment variables. If an attacker extracts these keys, they can interact directly with cloud APIs (e.g., DynamoDB or S3) from their local machine without further interaction with the vulnerable function. In addition, container reuse for performance optimizations can allow leftover data in `/tmp` to persist across invocations. - **Broken Access Control & Over-Privileged Functions**: Melamed highlights that 98% of thousands of reviewed functions are over-privileged due to developers using wildcard permissions (e.g., `s3:*` on all resources). Demonstrating the impact, Melamed shows how limiting IAM policies strictly to required actions on specific resources (e.g., `s3:PutObject` on a dedicated bucket) effectively blocks attackers from listing or compromising other buckets even if command injection occurs. - **Dependencies & Logging Challenges**: Microservice functions often contain only ~100 lines of custom code but pull in thousands of lines of external dependencies, increasing the likelihood of known vulnerable components. Traditional network monitoring is impossible; teams must rely entirely on provider-level log streams, which can be overwhelming to parse across millions of distributed function invocations.

### Takeaways Serverless architecture enables fine-grained least-privilege security at the function level, but realizing this benefit requires automated permission scoping, securing non-API triggers, monitoring cloud log services, and vetting third-party dependencies. Melamed points attendees to the OWASP Damn Vulnerable Serverless Application (DVSA) as an open-source project designed for practicing attacks and defenses in realistic serverless environments.

Related talks