Serverless sounds like a promise: no servers to patch, no machines to babysit, nothing sitting idle waiting to be exploited by a determined attacker. It is a genuinely useful shift for a great many businesses, but the word ‘serverless’ has quietly convinced a lot of them that the security conversation is over. It has not started, and treating it as finished is where the trouble tends to begin.
The Server Disappeared, the Risk Did Not
AWS Lambda functions run your code without you managing the underlying infrastructure, which removes an entire category of patching headaches that used to consume real engineering time. What it does not remove is everything you configure around that function: the permissions it holds, the triggers that invoke it, and the data it touches on its way through your systems. A function built with excessive permissions is just as dangerous as an overprivileged server, only now it is easier to overlook because there is no visible machine to prompt a security review. Nobody schedules a review of a resource that never shows up on the server inventory list.
This is precisely where dedicated AWS pen testing earns its value, because testers look specifically at how functions are chained together, what each one can reach, and whether an attacker who compromises one small function can pivot into something far more valuable elsewhere in your environment entirely.
When One Function Can Reach Everything
The most common Lambda mistake is not a coding flaw at all, it is an IAM role that grants far more access than the function actually needs to do its job. A function meant to resize uploaded images should never be able to read your customer database, yet in practice many are given broad permissions during development and never trimmed back once the project goes live, because nobody ever circles back to tidy up loose ends. Developers under deadline pressure reach for a broad role that definitely works rather than a narrow one that needs testing, and that shortcut quietly becomes permanent.
William Fieldhouse sees this pattern often enough that it barely surprises him anymore, though it still frustrates him on a client’s behalf.
“I once found a Lambda function meant purely to send email notifications that could also read and delete objects across the entire storage bucket without restriction. Nobody had built it that way deliberately, it had simply inherited a permission template from an earlier project and nobody ever asked whether it still made sense.”
— William Fieldhouse, Director of Aardwolf Security Ltd
Inherited permissions are one of the quietest risks in cloud environments precisely because nothing about them looks wrong at a glance during a normal working day. The function runs, the notifications send, everyone moves on to the next task. It takes someone deliberately testing what that function could do if compromised, rather than what it was intended to do, to expose the gap before an attacker finds it first and exploits it fully.
Treat Every Function Like It Could Be Compromised
Serverless architecture removes real burdens, but it introduces its own blind spots around permissions, triggers, and data flow that traditional server security checklists were never built to catch in the first place. Review what each function can actually reach, not just what it was designed to do, and get an independent penetration testing quote before an attacker maps those permissions for you and puts them to far worse use. A short audit now is considerably cheaper than explaining a data loss later.
