Home / Knowledge hub / Serverless security
Knowledge hub
Serverless security
Securing functions that run on demand, where you manage code but not servers.
What it means
Serverless computing lets you run code as small functions, such as AWS Lambda, that start when an event arrives and stop when done. You do not manage the servers. The provider handles the operating system and scaling, while you provide the code and its configuration.
Serverless security is what you must still do. The code is yours, so flaws in it are yours. So are the permissions each function holds, the events that trigger it and the secrets it uses.
Why it matters
Not having servers to patch removes some risk, but not the main ones. A function that builds a database query from input is open to SQL injection as much as any other code. A function with broad permissions gives an attacker a great deal if it is compromised.
Serverless also spreads logic across many small functions, each with its own triggers and permissions. Visibility gets harder, and a function nobody remembers can stay exposed for a long time.
How it shows up
You meet it in functions triggered by web requests, queues, file uploads, schedules and other services. OWASP's serverless list highlights injection through event data, broken authentication, over-privileged functions, insecure secrets and poor logging. Events are inputs too, not only HTTP requests.
Give each function its own narrow role, validate every event, keep secrets in a managed store, set timeouts and concurrency limits to contain cost and abuse, and log properly. Test the public entry points, such as the API in front, for access control and injection flaws as for any application.
Questions people ask
Serverless security, answered
Is serverless more secure?
Partly. The provider handles patching the platform. Your code, permissions, configuration and secrets remain your risk, and functions are often over-permissioned.
What is different from testing a normal app?
Entry points include events other than HTTP, such as queues and file uploads, and the platform hides the server. The flaws in your code and logic are the same kind.
Can injection happen in serverless?
Yes. If a function uses event data in a query, command or template without safe handling, it can be injected like any other code.
Why do permissions matter so much?
Each function runs with a role. If the function is compromised, the role is what the attacker gets, so narrow, per-function roles keep the damage small.
What about cost abuse?
Because functions scale and bill per run, a flood of requests can raise your bill. Throttling and concurrency limits protect the budget as well as availability.
Sources
Where this comes from
Related
Terms that sit next to this one
Least privilege
Giving every person and service the minimum access the job requires.
Overly permissive IAM
Cloud permissions broader than a job needs, so one leak reaches far.
Injection
Input that ends up running as a command instead of being read as text.
API gateway
A front door that routes API traffic and applies shared checks like auth and limits.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
What do your functions trust?
Functions behind a public API are tested like any other application entry point, and findings carry the request, the response and where possible the line of code. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.