serverless-security

Serverless Security

Rules (for AI agents)

ALWAYS

• Treat the execution environment as reused. The platform freezes it when the handler returns and thaws it for the next invocation, which may serve a different tenant. So a module-level global holding per-request state — a decrypted payload, an authorization decision, a tenant id, a connection bound to one caller's credentials — is visible to the next request. Cache only what is safe to share, and reset or scope everything else inside the handler.
• Treat /tmp as shared, persistent, and finite. It is the only writable path, it survives across invocations in the same environment, and a fixed filename written for one user is readable by the next. Use a per-invocation subdirectory, delete it before returning, and never read back a path without having written it in the same invocation.
• Validate the whole event, envelope included. The trigger's identity is not authentication: an S3 object key is chosen by whoever can PUT to the bucket, SQS message attributes and EventBridge detail are producer-supplied, and an API Gateway authorizer context is only as trustworthy as the authorizer. Validate against an explicit schema before any code touches the payload, and where a function has more than one trigger, check the source discriminant and route by allowlist.
• Give each function its own execution role with only the permissions its stated job needs. iam-best-practices owns policy scope and the escalation paths; what is serverless-specific is one role per function, never shared, because a shared role gives every function the union of what any of them needs.
• Set concurrency deliberately, and know which control you are reaching for. Reserved concurrency caps a function's parallel executions and is the denial-of-wallet control; provisioned concurrency pre-initialises environments to remove cold starts and bills for them whether or not they are used. Reserved capacity is also drawn from a shared account pool, so setting it per function is a decision about the account, not just that function.
• Bound the retry and failure path. Asynchronous invocations are retried by the platform, so one poison event becomes repeated executions, repeated spend, and repeated side effects if the handler is not idempotent. Configure the retry count, the maximum event age, and a dead-letter queue or failure destination — and for a batch source, report partial batch failures rather than failing the whole batch.
• Decide what the handler returns on a message it could not process. Returning success deletes the message and loses the data; raising on every message creates an infinite retry loop feeding a queue nobody drains. Both are silent.
• Set a timeout that reflects the work, and know it holds a concurrency slot for its whole duration — which is what makes a long timeout an amplifier during an attack rather than merely a slow response.