Before a serverless function ships, check who can call it, what it can reach, where its secrets live, what it trusts, and what happens at high volume. The twelve checks below come from AWS, Microsoft, Google Cloud and Cloudflare documentation, and fit into a pull request review or a pipeline gate.
Who can call it
- Is the endpoint meant to be public? AWS function URLs with auth type NONE, Azure functions set to anonymous and Cloud Run services that allow unauthenticated calls are all open to anyone. Record why.
- If it is not public, what authenticates callers? Microsoft says keys alone are not positive authentication. Use identity for sensitive data.
- Is CORS limited to named origins? Avoid wildcards.
What it can reach
- Does it have its own role or identity? Avoid sharing one broad role across functions.
- Are permissions limited to named actions and resources? AWS recommends adjusting the policy to only what is required before production, and IAM Access Analyzer can draft one from real usage.
- Are administrative and debug features off? Azure documents disabling admin endpoints, FTP and remote debugging when unused.
What it holds
- Are secrets out of code and out of committed configuration? AWS recommends Secrets Manager over environment variables for credentials. Cloudflare says not to put sensitive values in plain vars.
- Is the cache lifetime of fetched secrets compatible with rotation? The AWS extension caches for 300 seconds by default.
- Could a platform binding or managed identity replace a stored key? Both reduce what can leak.
What it trusts
- Is every trigger payload validated? Queue, storage and webhook inputs too. Azure states bindings do not validate for you.
- Are dependencies reviewed and the package built from a trusted pipeline? Lambda code signing can enforce signed deployments, though it does not judge the contents.
What happens at volume
- Is there a ceiling? Reserved concurrency in Lambda, or usage quotas for Azure Consumption plans, limit how far a flood or a loop can run.
How to run it
- Put the list in your pull request template, with a short answer for each item.
- Automate what can be automated: policy checks for wildcard permissions, scans for committed secrets, dependency scans for known vulnerabilities, and a check for public endpoint settings in infrastructure code.
- Keep the human review for the questions that need judgement: why it is public, what the identity may reach, what the input could contain.
- Record exceptions with an owner and a date.
Click through it at your own pace, or open it full screen.
Where this list is weaker. It reflects what these four providers document today. Other platforms differ, and the details change. Re-check a setting against the current provider documentation when it matters.
Quick check
Which single check removes the most risk?
Scoping the function's permissions. Most other failures are bounded by what the identity can reach.
Can all twelve be automated?
Most of the configuration checks can. The questions about intent, such as why an endpoint is public, need a person.
Safeguard's policies, gates and guardrails can run several of these checks on pull requests, and SBOM and dependency scanning cover the package side. The free scan is a quick start.
Sources
- Defining Lambda function permissions with an execution role, AWS documentation
- Control access to Lambda function URLs, AWS documentation
- Using code signing to verify code integrity with Lambda, AWS documentation
- Configuring reserved concurrency for a Lambda function, AWS documentation
- Use Secrets Manager secrets in Lambda functions, AWS documentation
- Securing Azure Functions, Microsoft Learn
- Authenticating, Cloud Run documentation
- Secrets, Cloudflare Workers documentation
Last reviewed: 19 October 2026.
