Serverless computing (AWS Lambda, Azure Functions, Google Cloud Functions) eliminates the need to manage servers. The cloud provider handles provisioning, scaling, patching, and infrastructure security. You write function code, define triggers, and the platform runs your code on demand.
This shifts the security responsibility significantly. You no longer worry about OS patching, server hardening, or network configuration at the host level. But you take on responsibility for function code security, IAM permissions, event source configuration, and data handling.
Function code vulnerabilities. Injection attacks (SQL, command, LDAP), insecure dependencies, and business logic flaws remain your problem. Serverless does not make application-layer vulnerabilities disappear. Apply the same secure coding practices as any application.
Over-privileged execution roles. Each serverless function runs with an IAM role that defines what cloud resources it can access. A common mistake is granting functions broad permissions like full S3 access or full DynamoDB access when they only need read access to a single table. If an attacker exploits the function, they inherit those permissions.
Event injection. Serverless functions are triggered by events: HTTP requests, queue messages, file uploads, database changes, or scheduled timers. Each event source is a potential input vector. An S3-triggered function that processes uploaded files must validate and sanitize the file just as rigorously as a web endpoint validates form data.
Insecure function configuration. Environment variables often contain secrets like database connection strings or API keys. Ensure these are encrypted and that only the function's execution role can access them. Better yet, retrieve secrets at runtime from a secrets manager.
Apply least-privilege IAM. Create a separate, narrowly scoped execution role for each function. If a function reads from one DynamoDB table and writes to one S3 bucket, its role should only permit those specific operations on those specific resources. This limits the blast radius of any compromise.
Validate all inputs. Treat every event as untrusted. Validate data types, lengths, and formats. Sanitize inputs to prevent injection. Serverless functions that parse JSON, XML, or file uploads are particularly susceptible.
Manage dependencies. Serverless functions rely on third-party packages just like any application. Use lockfiles, scan dependencies for known vulnerabilities, and keep them updated. Tools like Snyk, npm audit, and pip-audit integrate into serverless deployment pipelines.
Set appropriate timeouts and concurrency limits. A function without a timeout that enters an infinite loop will run until the platform's maximum (15 minutes on AWS Lambda), incurring costs and potentially causing downstream issues. Set timeouts to the minimum practical value. Concurrency limits prevent a sudden spike in invocations from exhausting downstream resources.
Serverless functions experience cold starts when no warm instance is available. During a cold start, the platform initializes the runtime, loads your code, and executes any initialization logic. Be cautious about what happens during initialization. Avoid fetching secrets or establishing database connections in a way that leaks information in logs.
Serverless functions generate logs in cloud-native services (CloudWatch, Azure Monitor, Cloud Logging). Enable structured logging that captures function invocations, errors, input summaries (not sensitive data), and execution duration.
Distributed tracing tools like AWS X-Ray or OpenTelemetry help you follow requests across multiple functions and services, which is essential for understanding complex serverless architectures and detecting anomalies.
Set up alerts for unusual patterns: spikes in invocations, elevated error rates, unexpected event sources triggering functions, or functions accessing resources they do not normally touch.