Serverless Functions & Cloud Security

What a serverless function actually is

Strip the marketing off and a serverless function is three things:

1. A short piece of code - usually one entry point that takes an event object and returns a result. JavaScript, Python, Go, Java, .NET, Ruby, custom runtimes via a thin shim. Code lives in a deploy package (zip, container image, or a managed runtime layer).
2. An event configuration - declaring what causes the function to run. HTTP routes via an API gateway, queue messages, blob/object events, scheduled timers, database streams, message-bus events, identity events.
3. An execution role - the cloud identity the function assumes when it runs. Permissions for whatever services the code needs to call (read a row from DynamoDB, write to S3, call SQS, etc.).

When an event arrives, the platform allocates an isolated execution environment (a per-invocation micro-VM on AWS - Firecracker - and equivalents on Azure and GCP), copies your code in, runs it for at most a few minutes (varies by provider; Lambda caps at 15 minutes), and discards the environment. From your side: no servers visible, no nodes to patch, no operating system to maintain. The platform handles all of that.

The serverless name is a marketing term - there are obviously servers underneath. The accurate framing is functions as a service: the unit of deployment is a function, the unit of billing is the millisecond of execution, and the platform owns everything between your code and the silicon.

Why use serverless

The model maps cleanly onto a specific shape of workload - event-driven, intermittent, with bursty concurrency:

• Pay only when running. No idle compute charges. A function invoked 1,000 times a day costs cents to dollars rather than the monthly minimum of a small VM.
• Scale-to-zero and scale-to-thousands automatically. No provisioning capacity ahead of demand. Spikes that would have required pre-warming a fleet are handled by the platform.
• No server patching. The cloud upgrades the OS, runtime, and language version on a published schedule. You take the deprecation hit when your runtime reaches EOL, but day-to-day patching disappears.
• Tight integration with cloud event sources. S3 → Lambda, Blob → Function, GCS → Cloud Function is a one-line wiring that would have required a polling daemon a decade ago.
• Smaller per-workload security surface. No kernel to share, no node to compromise, no DaemonSet to misconfigure. The unit of compromise is one function execution.
• Fast development loop. Deploy in seconds, roll back in seconds, version every change. Great for glue code, internal tools, and event-driven plumbing.

The typical fit: API endpoints that don't need persistent state, ETL pipelines that fire when a file lands, scheduled jobs, fan-out and fan-in patterns, lightweight integrations between SaaS services, and any "respond to this cloud event" use case.

The good and the bad

Serverless is good for some shapes, bad for others. The honest tradeoff matrix:

A working heuristic: if your workload is event-driven, intermittent, mostly stateless, and finishes in under 15 minutes, serverless is usually the right default. If it's sustained throughput, long-running, or has a hard latency budget under 100ms p99, containers or VMs are usually a better fit.

The trust boundary

For each function invocation, the security-relevant boundary is straightforward:

• The execution environment is per-invocation, hypervisor-isolated. On AWS, every Lambda invocation runs in a Firecracker micro-VM dedicated to one customer. Azure and GCP have similar isolation. Two of your functions cannot share a kernel; two customers' functions definitely cannot.
• The function's identity is its execution role. Whatever permissions that role has, the function has. There is no node identity, no shared service-account token, no host-level credentials to fall back to.
• The event source is the entry point. Whatever calls the function - API Gateway, an HTTP function URL, S3 events, queue messages - is the threat surface. Untrusted input enters the function via the event payload.
• The function's outbound calls are bounded by its role. If the role can read a single DynamoDB table, that's the blast radius. Per-function least-privilege roles are the difference between "one function compromised" and "one function got the keys to everything."

The platform genuinely makes the boundary stronger than a long-lived container or VM in some ways - fresh execution environment per invocation, hypervisor isolation by default, no host to patch. It also makes some kinds of compromise cheaper: stealing a function's IAM credentials and using them outside the function is easy if the function leaks them, and the function only needs to be compromised once to do that.

The seven risk categories that matter

Serverless security in the cloud collapses into seven categories. The names differ across vendors; the threats don't.

Event injection - untrusted payloads

The most underestimated serverless risk. A function triggered by an event receives a structured payload - and that payload often contains attacker-controlled fields.

Some real entry points:

• S3 / Blob object events. The object key is in the event. An attacker who can upload a file with a path like ../../etc/passwd or a name containing shell metacharacters has just gotten that string into your function.
• SQS / queue message bodies. If anything outside your control can write to the queue (cross-account, public SQS via SNS, a chain of services), the message body is attacker-controlled.
• API Gateway / HTTP requests. Same as any web app - headers, body, path, query, cookies. Function URLs (no API Gateway) skip even basic input validation that gateway features provide.
• EventBridge / event-bus events. Sources you trust can be compromised; sources you didn't realize were writing to the bus can inject too.
• Database streams. A record inserted by a vulnerable upstream service flows into the stream and into your function.
• Cognito / Auth events. User-controlled fields (custom attributes, names) get passed to post-confirmation Lambda triggers.

Defenses

• Validate every field of the event before using it. Even fields the docs say are "system-generated" - they often include user-supplied strings.
• Schema-validate at the function entry. JSON Schema, Pydantic, Zod. Reject malformed input fast and loudly.
• Treat event-source IDs as untrusted. An object key, a message ID, a record ID - even those need to be sanitized before they flow into a shell command, a SQL query, a path operation.
• Don't eval event data. Sounds obvious; happens anyway in glue functions that dynamically construct paths or queries from event fields.
• Constrain who can push to the source. Bucket policies, queue policies, event-bus rules. A queue that should only receive messages from one account shouldn't be writable cross-account.

Identity sprawl & per-function roles

The right pattern: one IAM role per function, each scoped to the minimum permissions that function needs. The frequent reality: a small number of broad "this role works for most of our Lambdas" roles, reused across dozens of functions, all over-permissioned.

Why this drifts:

• Defining a tight role requires knowing exactly which APIs the function calls. As the function evolves, the role doesn't.
• Copy-pasting an existing role is faster than authoring a new one.
• "It works locally with admin; let's deploy and tune later." There is no "later."
• Resource-level conditions are verbose to write; wildcards win.

The blast-radius math: if 50 functions share one role with s3:* on *, then any of those 50 functions being compromised gives the attacker access to every S3 bucket in the account. With 50 distinct roles each scoped to one bucket, the blast radius is one function's worth of data.

Defenses

• One role per function. Generate via IaC (Terraform / SAM / Bicep / CDK) so authoring is automatic and consistent.
• Tighten with Access Analyzer / unused permissions. Each cloud now has a tool that reports which permissions in a role have actually been used in the last N days. Cut the unused ones.
• Resource-level constraints. Not s3:GetObject on *; s3:GetObject on the specific bucket ARN, with a key prefix condition if possible.
• Permission boundaries. On AWS, set a permission boundary on every function role so it cannot escalate even if its inline policy gets modified.
• Detect role drift. SIEM-side detections for "role got a new permission" or "function role used outside the function's typical region/time." Both are signals worth alerting on.

Supply chain - every dep is runtime

In a long-lived container, dependencies are pulled at build time and frozen. In a serverless function, dependencies are still pulled at build time - but the cold-start surface means every dependency is loaded on every fresh execution environment. The attack window is identical, but the velocity of "I just upgraded a dependency and it shipped to prod" is higher because deploy cycles are shorter.

Real serverless supply-chain incidents:

• Typosquatted npm packages - request vs requst, aws-sdk vs aws-sdk-js. A function that depends on the wrong package by one letter exfiltrates credentials on the first cold start.
• Dependency-confusion attacks - a public registry name that shadows an internal package. Pull resolves to the public (malicious) copy.
• Compromised maintainer accounts - event-stream (2018), Shai-Hulud / chalk (2025), repeated PyPI / npm token leaks. Function gets a new transitive dependency on the next deploy.
• Lambda Layers from third parties - public layers are convenient and almost never audited. Trust here is trust in the layer publisher's pipeline.

Defenses

• Lockfiles, pinned by hash. package-lock.json, requirements.txt with hashes, go.sum. npm ci / pip install --require-hashes in your build.
• Scan dependencies in CI. Trivy, Snyk, Dependabot, OSV-Scanner, OpenSSF Scorecard. Fail the build on HIGH/CRITICAL CVEs.
• SBOM per deploy. Track exactly what shipped. When the next CVE drops, query the SBOM rather than rebuild-and-pray.
• Signed packages. Cosign / Sigstore for container-image functions. AWS Signer for Lambda zips on AWS. Verify at the deploy boundary.
• Use a private mirror or proxy. Verdaccio, Artifactory, JFrog, GitHub Packages. The proxy is the chokepoint where you enforce policy.
• Avoid third-party Lambda Layers in prod unless you have ownership or verifiable provenance.

See the CI/CD page for the pipeline side of this same problem.

Secrets, env vars, and config

Every serverless platform offers "environment variables" as the easy way to inject configuration. They're convenient, they're standard, and they're the wrong place for secrets.

Why env vars are leaky:

• Visible in the console to anyone with read access on the function. That's almost always a wider audience than "people who should know the production database password."
• Visible in CloudFormation / Terraform / Bicep templates - and those templates live in source control. Even encrypted-at-rest, they're decrypted when applied.
• Visible in aws lambda get-function-configuration / equivalent. Any principal with that permission gets the secret.
• Easy to log accidentally. console.log(process.env), an error stack with environment dump, a verbose-mode telemetry payload.
• Hard to rotate without redeploying.

Defenses

• Use a secrets store. AWS Secrets Manager / SSM Parameter Store (SecureString), Azure Key Vault, Google Secret Manager. Fetch at function init; cache for the warm-execution lifetime.
• Use the cloud's "extension" pattern. Lambda Extensions, the Azure Functions secret-manager binding, GCP's volume-mount of Secret Manager. Secrets never touch env vars.
• Encrypt env vars at rest with a KMS key you control, not the default service key. Logs the decryption to CloudTrail; you can see when anyone reads them.
• Don't ship secrets in env vars even for "non-prod." Non-prod credentials have a way of becoming prod credentials.
• Scan logs for secrets continuously. A function that accidentally logged its API key once will keep doing it. Detect and rotate.

Networking, egress, and VPCs

By default, a serverless function runs outside your VPC. It has internet egress (which means it can call any external API) and can be invoked over the internet through an API Gateway or Function URL. The "outside the VPC" default is a security choice with two faces:

• The good face: functions can scale to thousands of concurrent executions without exhausting your VPC's IP space. They can call public APIs without a NAT gateway. Cold-start latency is lower because no ENI attachment is needed.
• The bad face: any compromise has unrestricted outbound to the internet. Egress filtering at the platform level is minimal. Calling an external command-and-control server, exfiltrating data, or hitting an external API key validator is unimpeded.

When you should attach the function to a VPC

• Function needs to reach a private resource - an RDS instance, an internal API, a private DynamoDB endpoint, an EFS mount.
• You want to enforce egress controls via NAT gateway with allow-list rules or via a transit gateway with a firewall.
• Compliance requires "all traffic stays within our network perimeter."
• You want VPC Flow Logs to capture function network behavior.

When the VPC isn't worth it

• Function only calls public AWS APIs (S3, DynamoDB, SQS) - those can be reached via VPC endpoints when needed but don't require VPC attachment for general use.
• Function is purely event-glue and never makes outbound network calls.
• Cold-start latency budget can't absorb the ENI attach time (much faster than it used to be - Lambda Hyperplane ENIs reduced this dramatically - but still non-zero).

Whether or not you VPC-attach, egress to known-bad destinations should be blocked at some layer - a NAT gateway allow-list, a managed firewall (AWS Network Firewall, Azure Firewall, Cloud NGFW), or runtime egress policy if your CNAPP supports it.

Denial of wallet

The serverless equivalent of DDoS. Instead of taking your application offline, the attacker drives up your invocation count and your cloud bill becomes the casualty. Recent incidents have reported five-figure damages from a single weekend.

Common vectors:

• Public function URLs. A URL like https://abc.lambda-url.us-east-1.on.aws/ with no authentication is a free invocation source for anyone with the URL.
• Unrate-limited APIs. An API Gateway in front of a function with no throttling - every request is one paid invocation, every response is one paid response.
• Recursive event loops. Function writes to S3; S3 event triggers the same function. Without a deduplication step or output-prefix isolation, this is an infinite loop billed per invocation.
• Amplification through dependencies. Function invokes another service per request that costs money - Comprehend, Translate, Bedrock, third-party APIs you pay per call. One attacker request, multiple paid downstream calls.
• SQS / Kafka pile-ons. Producer floods a queue; the function scales to drain it; bill is the function-invocation count.
• Cold start as a budget vector. A pattern designed to keep forcing cold starts (different deploy versions, scale-out faster than warm-pool replenishment) costs more per invocation than a warm one would.

Defenses

• Reserved / max concurrency per function. A hard cap on concurrent executions. The function can be 100% used by the attack - but no more than that.
• API Gateway throttling. Per-route rate limits, per-API-key quotas, usage plans. The 1990s WAF-grade throttle is back in style for the right reason.
• Budget alarms and auto-pause. AWS Budgets with anomaly detection, Azure Cost Alerts, GCP Budgets - wire them to SNS / EventBridge / Pub/Sub and trigger a Lambda that pauses concurrency or revokes the function URL.
• Idempotency keys. Detect and short-circuit duplicate work before it bills compute.
• Output prefix isolation. If your function reads from bucket/input/ and writes to bucket/output/, configure the S3 event trigger to filter on input/ only. No recursion possible.
• Authentication on every public-facing function. Lambda Function URLs default to authenticated. Don't switch them to NONE unless you've thought about why.
• WAF in front of public API Gateways. Rate-based rules, IP allow/deny, AWS Managed Rules. The same WAF that protects your web apps catches the serverless DoW path.

Logging & observability

The serverless equivalent of "did anything weird run last month?" is "do we have the logs to answer that?" - and the default answer is often no.

What's missing relative to a VM or container:

• No persistent host to inspect after the fact. The execution environment is gone.
• No kubectl exec / SSH for a live forensics session.
• No host-level process / network logs unless you opt in.
• Function logs are scoped to your console.log / print calls - by default, that's it.

What good looks like

• Structured logging. Every log line is JSON with consistent keys (request ID, function name, version, latency, status). Searchable, aggregatable, useful in incident.
• Centralized log shipping. CloudWatch Logs → S3 / SIEM, Azure Functions → Log Analytics, Cloud Functions → Cloud Logging. Logs leave the cloud's default 7-day retention immediately.
• Distributed tracing. AWS X-Ray, Azure Application Insights, Cloud Trace, or OpenTelemetry. A request that touches three functions and four services should be traceable end-to-end.
• Per-function alarms. Error rate > threshold, duration spike, throttle count rising. Cheap to set up; high value when something goes sideways.
• Audit-log the management plane. CloudTrail / Activity Log / Cloud Audit Logs for function create / update / role-change events. A new function with admin IAM is a SIEM-worthy signal.
• Runtime telemetry tools. Datadog, Dynatrace, Lumigo, Thundra, the cloud-native CNAPP runtime add-ons. They instrument the runtime to capture syscall-level and dependency-call telemetry without code changes.

AWS, Azure, and GCP side-by-side

Three major FaaS platforms, broadly similar in shape, different in details.

The three converge over time as each picks up the others' best ideas. The differences worth caring about: max execution time (15 min cap on Lambda is sometimes a deal-breaker), VPC attach behavior (Lambda's Hyperplane is the cleanest of the three), and how secrets are referenced (Azure's Key Vault reference syntax is the most ergonomic).

Hardening checklist

The non-negotiable serverless hardening list:

Layer on top: a secrets store for anything sensitive (never env vars), egress controls if the function is internet-callable, and runtime / CNAPP telemetry for the things logs can't show you.

Common pitfalls

• Shared "generic Lambda role" across many functions. One leaky function compromises all the others. Per-function roles.
• Secrets in env vars. Console-readable, log-leakable, hard to rotate. Secrets store instead.
• Public function URLs with AuthType: NONE. Easy to set up; weekend-sized cloud bills when fuzzed. Authenticate or rate-limit, ideally both.
• No reserved concurrency or budget alarms. The platform will happily scale your function (and your bill) into the stratosphere on attack.
• Recursive S3 event loops. Function writes to the same bucket prefix it reads from. Either filter the trigger to a different prefix or write to a different bucket.
• Trusting event fields the docs call "system-generated." Many of those include user-controlled strings. Validate.
• Third-party Lambda Layers / extensions without provenance review. They run inside your execution environment with your IAM credentials. They're as much your code as your code is.
• Deploying from a developer laptop with long-lived keys. Same anti-pattern as the rest of cloud. See the CI/CD page for the OIDC-federation fix.
• No centralized logging. Default retention is short; without shipping logs out, you have no after-the-fact forensics.
• Trying to make a long-running batch job fit in a function. If the work takes 14 minutes today, it'll take 16 tomorrow. Use Step Functions / Durable Functions / Workflows or move to a container.

Further reading

Vendor docs & best practices

• AWS Lambda - security overview
• AWS Lambda Operator Guide - Security
• Azure Functions - security concepts
• Google Cloud Functions - securing your function

Standards & frameworks

• OWASP Serverless Top 10
• OWASP Serverless Cheat Sheet
• CISA - Serverless Cloud Security Mitigations & Best Practices (PDF)

Frameworks & tooling

• Serverless Framework
• AWS SAM
• AWS CDK
• Check Point CloudGuard Workload & other serverless-runtime tools (most CNAPPs ship one)

Related CSOH pages

• Containers & cloud security - what serverless functions move workloads away from.
• Kubernetes & managed Kubernetes - the other dominant cloud-native compute model.
• CI/CD for cloud deployments - the pipeline that ships function code.
• CSPM vs CNAPP - the tools that watch function fleets in production.
• Glossary - every term on this page, defined.

FAQ

Is "serverless" the same as "FaaS"?

Functions-as-a-service is the specific form this page covers - Lambda, Azure Functions, Cloud Functions. Serverless is the marketing umbrella that also includes serverless containers (Cloud Run, Fargate, Container Apps), serverless databases (DynamoDB on-demand, Aurora Serverless, Cloud Spanner), and a growing list of "no infrastructure to manage" services. This page is FaaS-specific; the Containers page covers the serverless-container variants.

Should I write everything as serverless functions?

No. Functions are great for event-driven, intermittent, mostly stateless workloads that finish in under 15 minutes. They get expensive at high sustained throughput, awkward for long-running work, and lock you to one cloud's event-source wiring. The "rebuild everything as Lambdas" pattern from 2018 burned a lot of teams - most have since migrated steady-state services back to containers, kept serverless for the parts where it actually fits.

How is cold-start security-relevant?

Two ways. First, every cold start re-loads all dependencies - meaning a compromised dependency activates on every cold start (not just at deploy). Second, init-time code paths (loading secrets, opening connections) run differently from steady-state warm code paths - bugs that only happen during init can be harder to catch.

Can a function be exploited like a regular web app?

Yes. Injection, deserialization, broken access control, SSRF - every OWASP-class issue applies. The execution environment is shorter-lived and the IAM blast radius is usually narrower, but the application-layer surface is the same. Add event-source-specific injection as an extra category that doesn't exist for traditional servers.

How does this relate to zero trust?

Serverless makes some zero-trust principles trivially easy and others harder. Per-invocation isolation and per-function identity are zero trust by default - "verify explicitly" and "least privilege" come almost for free. What's harder: network-level segmentation (the platform abstracts the network away) and continuous verification (no host to inspect, no agent to run, so you depend on the platform's telemetry and your own logging).