What is Serverless?

Serverless means the cloud provider manages the servers. You write a function, upload it, and the provider runs it when a request arrives. You do not provision, patch, or scale any operating system.

AWS Lambda is the compute service. It runs your code in response to events. API Gateway is the front door. It receives HTTP requests from the internet and routes them to your Lambda function.

API Gateway

API Gateway is a managed service that sits between the internet and your Lambda functions. It handles:

• Routing — maps HTTP methods and paths to Lambda functions
• Throttling — default 10,000 requests/second per region
• Authorization — IAM, Cognito, or custom Lambda authorizers
• Stages — deploy to dev, staging, prod with separate URLs

Two types: REST API (full-featured, WAF support, request validation) and HTTP API (cheaper, faster, fewer features). This workshop uses REST API.

Each deployed endpoint gets a URL like: https://<api-id>.execute-api.<region>.amazonaws.com/<stage>/

Security note: API Gateway does not validate request bodies by default. Input validation is your responsibility in the Lambda code — which is why injection attacks work.

How a Request Flows

flowchart TD
    A[Browser / curl] -->|HTTPS request| B[API Gateway]
    B -->|Invoke| C[AWS Lambda]
    C -->|Execute| D[Your Python code]
    D -->|Return| E[HTTP Response]
    C -.->|IAM role| F[AWS Services<br/>S3, DynamoDB, etc.]

There is no EC2 instance, no Nginx, no Docker container in between. The Lambda function starts, runs, and shuts down automatically.

Lambda Internals

Firecracker microVM

Every Lambda function runs inside a Firecracker microVM — a lightweight virtual machine created by AWS. Firecracker boots in ~125ms and provides hardware-level isolation between functions. Each execution environment is a separate microVM with its own kernel, so one customer’s code cannot access another’s memory or filesystem.

This is why the Lambda sandbox user is sbx_user1051 — you will see this when you run id in the command injection lab.

Invocation

An invocation is one execution of your function. API Gateway receives a request → invokes Lambda → Lambda runs your code → returns the response. Each invocation is billed by duration (in 1ms increments) and memory allocated.

Cold Start vs Warm Start

Cold start creates a new execution environment from scratch. Warm start reuses an existing one. The /tmp filesystem persists between warm invocations — which is why our pickle RCE lab can verify file creation with a separate request.

Security implication: Data in /tmp and global variables survive between invocations. If one request writes sensitive data to /tmp, the next request (possibly from a different user) can read it.

Timeout and Limits

If a function hits the timeout, Lambda kills it and API Gateway returns 502 Bad Gateway. You will see this in the ReDoS lab — a single crafted string makes the function run until timeout.

Concurrency

Concurrency = number of invocations running at the same time. Each concurrent request gets its own execution environment (its own Firecracker microVM).

If 100 users hit your API at the same time, Lambda spins up 100 microVMs. If you hit the concurrency limit, additional requests are throttled (429 Too Many Requests).

Security implication: An attacker who triggers many concurrent invocations (e.g., via ReDoS) can exhaust your concurrency limit and deny service to legitimate users across ALL Lambda functions in the account.

Reference: AWS Lambda — How it works

What changes for security?

Traditional servers have a known attack surface: SSH, open ports, unpatched OS libraries. Serverless removes those, but introduces a different set of risks:

The code vulnerabilities are the same. The infrastructure vulnerabilities are different.

OWASP Serverless Top 10

The OWASP Serverless Top 10 is a list of the most critical security risks in serverless applications. In this workshop we exploit all ten.

Next step: Injection