Serverless function security checklist for SaaS teams
Secure SaaS serverless functions with per-function identities, protected invocation, validated events, managed secrets, supported runtimes, bounded retries and useful logs.
In this guide
What is a serverless function security checklist?
A serverless function security checklist protects the code, identity, event sources, configuration and data paths of functions that run on a managed cloud platform. Each function still has an attack surface: an HTTP URL may be public, an event producer may be over-trusted, or an execution role may expose unrelated resources. Build a separate trust boundary for each function and adapt provider-specific controls; AWS Lambda is used here as a documented example.
Inventory triggers, data and callable paths for every function
List HTTP endpoints, queues, storage events, schedules, identity providers and service integrations that can invoke each function. Record the expected caller, event format, data classification, downstream services, owner and failure behavior. Include preview and old function versions so forgotten endpoints do not remain exposed.
Give each function a dedicated execution identity
Separate functions with different data or duties and grant each runtime role only the resources and actions it needs. Keep deployment permissions separate from runtime permissions; a function that reads one table should not inherit account-wide administration. AWS Lambda documents execution roles and least privilege; apply the equivalent workload identity model on other platforms.
Decide explicitly whether an HTTP trigger is public
Review both the function's authentication setting and its resource-based invocation policy. If a route is intentionally public, validate requests and authorize sensitive actions in the application; otherwise require platform authentication or place it behind an authenticated gateway. AWS Lambda function URLs with AuthType NONE require a public resource policy before unauthenticated invocation is possible.
| Function and trigger | Trusted caller and event | Runtime permissions | Secrets and data | Retry, alert and owner |
|---|---|---|---|---|
| Public API handler | ||||
| Queue consumer | ||||
| Scheduled maintenance job |
How do you secure serverless configuration and deployment?
Keep secret values in a managed secret store
Use environment variables for non-secret configuration where appropriate, but do not treat encryption of the function configuration as a reason to put long-lived credentials there. Prefer a managed secret service or short-lived workload identity, restrict which function can read each secret, and rotate credentials through a tested release. AWS recommends Secrets Manager for database credentials, API keys and authorization tokens instead of Lambda environment variables.
Run supported runtimes and update function dependencies
Track runtime support dates, language package vulnerabilities and base-image updates. Managed platforms may patch parts of a managed runtime, but the team still owns its function code and dependencies; container-based functions also need rebuilt and redeployed images. Test upgrades with the real event shape and rollback plan.
Protect the deployment path and configuration changes
Review who can publish a version, update a trigger, change an execution role or alter environment settings. Keep production approval separate from ordinary code contribution and protect the build identity. Scan dependency and deployment artifacts, and retain a history that shows which reviewed change created the live function configuration.
How do you harden serverless event handling and operations?
Treat every event payload as untrusted input
Validate required fields, types, size and allowed values before using an event. Verify the authorized producer through the platform policy, and do not rely on a customer-supplied tenant ID or event name as proof of permission. Apply the same object-level authorization checks as an HTTP API before reading or changing customer data.
Design retries, timeouts and duplicate delivery deliberately
Set execution timeouts and concurrency limits to fit the downstream service. Make handlers idempotent so a retry or duplicate event does not charge, notify or mutate a customer twice. Configure bounded retry and dead-letter behavior for asynchronous work, and alert on repeated failures instead of letting a poison event loop indefinitely.
Log enough to investigate without copying sensitive payloads
Record function version, request or event correlation ID, outcome and useful security decisions. Avoid writing full credentials, tokens, uploaded content or personal records to logs. Restrict log access and test alarms for unexpected public invocation, permission changes, error spikes and exhausted retries.
Serverless function security FAQs
Are serverless functions secure by default?
The provider operates parts of the runtime platform, but your team still configures invocation permissions, execution identity, code, dependencies, secrets, network access and data handling. Review the shared responsibility boundary for the actual service and deployment mode.
Should each function have its own role?
Separate roles are a strong default when functions have different permissions or data access. Sharing a role can make a small deployment easier, but it expands the impact of a compromised function and makes reviews less precise. Keep shared roles narrow and document why they are shared.
Can environment variables contain API keys?
Avoid storing long-lived API keys, database passwords or authorization tokens directly in function environment variables. Use a managed secret service, limit secret retrieval to the function that needs it, and plan rotation. Provider encryption at rest does not remove access-control or log-exposure risks.
Do function URLs need a separate security review?
Yes. Confirm their authentication mode, resource-based policy, allowed caller, application authorization and logging. A URL's obscurity is not access control, and a function configured for public access should be treated like any internet-facing API.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- Managing Permissions in AWS LambdaAmazon Web Services
- Control Access to Lambda Function URLsAmazon Web Services
- Working with Lambda Environment VariablesAmazon Web Services
- AWS Lambda Runtimes and Shared ResponsibilityAmazon Web Services