Cybersecurity glossary
What is Serverless Security?
Learn what serverless security covers—function IAM, event injection, secrets, and cold-start supply chain—and how to harden Lambda-style platforms without a long-lived server.
Definition
Serverless security is the practice of protecting event-driven functions and managed backends (FaaS, BaaS) where the provider runs the host: identity, event inputs, dependencies, secrets, and downstream permissions become the control surface instead of SSH and patch windows.
Why serverless security is a different job
There is no SSH, no weekly AMI bake, and often no VPC in the first draft. That does not shrink the blast radius. A function’s execution role can still delete databases, and an open function URL is still a public application.
Serverless security is therefore identity-first and event-first. The provider hardens the host; you harden who may invoke the function, what the event is allowed to contain, and what cloud APIs the runtime role may call.
The serverless request path
An event arrives
HTTP, queue, object-created, cron, or another function. Triggers are part of the trust boundary.
The platform authenticates the invoke
Resource policies, IAM, API keys, or JWT authorizers decide if the event is accepted.
The runtime starts with an execution role
Temporary credentials are injected. Anything that role can do, the code can do.
The handler processes untrusted input
Object keys, bodies, and headers need the same validation as any web app.
Downstream calls use that role
S3, SQL, webhooks, and metadata-adjacent URLs execute with function privileges.
Control surfaces that replace the old server
Execution role
One function, one role, explicit actions and resources. No AdministratorAccess “to make it work.”
Trigger policy
Who may invoke: a specific bucket, a private API, a queue in this account—not Principal:*.
Deploy artifact
Dependencies, layers, and container images need scanning and pinning like any other build.
Data in the event
Injection, path traversal in object keys, and XSS in generated emails start here.
Serverless risks versus traditional VMs
| Concern | VM-centric | Function-centric |
|---|---|---|
| Patch the host | You own the AMI cadence | Provider patches; you still patch libraries in the zip or image |
| Network exposure | Security groups and public IPs | Function URLs, API Gateway, and overly open resource policies |
| Secrets | Files and agents on disk | Env vars, encrypted config, and vault retrieves at cold start |
| Persistence | Malware on the disk | Backdoored layers, poisoned dependencies, and rogue extra triggers |
| Lateral movement | SSH keys and subnet reachability | The execution role’s IAM graph |
Serverless security checklist
- Create a dedicated execution role per function with explicit actions and resource ARNs.
- Lock triggers: no anonymous function URLs unless the product is truly public, then rate-limit and WAF.
- Validate and encode every event field the way you would a web request body.
- Scan deployment packages and layers; pin versions and verify signatures where possible.
- Fetch secrets at runtime with IAM; do not bake them into env vars, images, or repo configs.
- Put sensitive functions in a VPC only when they must reach private data—and still restrict egress.
- Minimize timeout and memory so runaway recursion and resource bombs cost less.
- Log invocations and downstream API errors; alert on new triggers, role changes, and spikes in 4xx/5xx.
The practical takeaway
Serverless security protects functions by tightening invoke policy, execution IAM, event handling, and deploy artifacts—not by patching a guest OS you do not see.
Treat each function as a miniature service with its own identity. If the role is broad and the trigger is public, you have rebuilt an open server without the honesty of a public IP.
Related security terms
Cloud IAM
The execution role of a function is the primary authorization boundary.
Workload Identity
Functions should assume scoped roles rather than embed long-lived keys.
Secrets Manager
Preferred store for values functions must retrieve at runtime.
Software Supply Chain Attack
Layered runtimes and fat deployment zips are a common poison path.
Server-Side Request Forgery (SSRF)
URL-fetching functions can still reach metadata and internal APIs.
Frequently asked questions
What is serverless security in simple terms?
You still write code that handles events, but you do not patch a VM. Security shifts to the function’s IAM role, the events it trusts, the packages in the deploy artifact, and the secrets it can read.
Does serverless mean no server to attack?
You cannot SSH to the host, but you can invoke the function, poison its event, steal its role, or abuse a mis-set resource policy that lets the internet call it.
What is the biggest serverless failure mode?
An execution role with wildcard permissions plus a trigger that anyone can fire. The function becomes a confused deputy for the entire account.
Are environment variables OK for secrets?
They are convenient and often visible in consoles, crash traces, and copies of the function config. Prefer a secrets manager retrieve at runtime with IAM, and never commit values into the deploy package.
How do event-driven injections work?
Untrusted JSON, emails, S3 object names, or HTTP bodies are passed into shells, queries, or HTML. Serverless does not sanitize events for you.
Do I still need WAF and auth on APIs?
Yes. An API Gateway or function URL without auth is a public server. Rate limits, IAM, JWT, and input validation still apply.
How is this different from container security?
You rarely manage the kernel, but you also cannot install a host IDS. Focus on identity, event trust, artifact scanning, and least-privilege triggers.
References
Explore authoritative guidance and frameworks related to serverless security.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.