Serverless Security

Serverless (AWS Lambda, Azure Functions, GCP Cloud Functions/Run) runs code without managing servers. For the attacker, each function is a small surface with its own weaknesses: secrets in environment variables, a role/identity with abusable permissions, vulnerable dependencies, and injection if it processes untrusted input. And since functions usually have cloud permissions, compromising one is often the jump into the rest of the account.

Why they’re a target

A function isn’t “just code”: it runs with an identity (execution role) that has permissions over other cloud resources. If you abuse the function (injection, vulnerable dependency) or simply read its secrets, you inherit those permissions → escalation and lateral movement (see IAM Abuse and Privilege Escalation).

Attack vectors

Secrets in environment variables

# functions store config/secrets in env vars (common, insecure practice)
aws lambda get-function-configuration --function-name X   # shows Environment.Variables
# inside the function: printenv / os.environ -> API keys, DB creds, tokens

Execution-role abuse

# the function runs with an IAM role -> its credentials are in the environment
# AWS: AWS_ACCESS_KEY_ID/SECRET/SESSION_TOKEN in the function's env vars
# if you get RCE in the function (injection) -> steal those credentials -> cloud-iam

Injection and untrusted input

# the function processes events (HTTP, queues, S3...); if it doesn't validate:
command injection, SSRF (-> metadata/other services), path traversal, deserialization
# a function behind API Gateway is a webapp -> the Web section attacks apply

Vulnerable dependencies and deployment

# vulnerable npm/pip packages in the function bundle
# deployment permissions (create/update functions) -> backdoor or PassRole (cloud-iam)

PassRole / create functions (escalation)

# with lambda:CreateFunction + iam:PassRole over an admin role:
# create a function that runs as admin and executes your code (see cloud-iam)

Enumeration

# AWS
aws lambda list-functions ; aws lambda get-function --function-name X   # code + config
# Azure
az functionapp list ; review application settings (secrets)
# GCP
gcloud functions list ; gcloud functions describe X ; gcloud run services list

For the defense

Secrets outside code/env: use Secrets Manager/Key Vault/Secret Manager, not cleartext env vars.
Least privilege on the execution role: the function should only do what it needs (limits a compromise’s damage).
Validate all event input (injection, SSRF); scan dependencies (SCA) and the bundle.
Don’t grant CreateFunction+PassRole together to non-admin identities; review deployment permissions.
Logging (CloudWatch/App Insights/Cloud Logging) and time/resource limits; WAF in front of HTTP functions.

Testing checklist

Enumerate functions and their configuration (code + env vars)
Secrets in environment variables
Execution role/identity and its permissions (IAM Abuse and Privilege Escalation)
Injection/SSRF if it processes untrusted input
Role credentials stealable via RCE in the function
Vulnerable dependencies in the bundle
PassRole + CreateFunction → escalation
HTTP functions treated as a webapp (Web section)