Serverless & Cloud Function Penetration Testing

We start by mapping every function, its triggers, the resources it can reach, and the identity it runs as. Using the cloud provider’s APIs, Burp Suite against the HTTP entry points, and a review of your infrastructure-as-code, we build a picture of how data and permissions flow across the application. That map tells us which functions are reachable by an attacker and which ones hold dangerous power.

We test every way into the application: API Gateway routes, Lambda function URLs, and functions triggered indirectly by uploads, queue messages or database changes. Event-injection testing is central here. When a function processes a file dropped in a bucket or a message on a queue, we control that input and probe for injection, deserialization and logic flaws, because those triggers are trusted far more than they should be.

Once we can influence a function, the question is what its role lets us do next. We analyse the attached IAM policies for excess permissions and known escalation paths, such as a role that can rewrite its own policy, pass a more powerful role, or read secrets it never needed. Chaining a low-value entry point to an over-permissioned role is how a single serverless bug becomes account-wide compromise.

Where we find a real path, we prove it inside your account against test resources: reaching data the function should not, extracting a secret, or invoking a privileged action. You get the written report within days, with reproduction steps and the exact policy or code change to fix it, a live walkthrough, and a free retest.

The most common and most damaging finding. Functions are frequently granted broad permissions for convenience during development and never tightened, so a bug in one function exposes storage, databases and other services across the whole account. Least privilege per function is the fix, and almost nobody does it fully without being shown the gap in their own environment first.

Developers validate HTTP input but treat data arriving from an internal queue, a storage event or a database stream as trusted. An attacker who can place a crafted object in a watched bucket or a poisoned message on a queue reaches the function with input that was never sanitised, opening the door to injection and deserialization attacks.

API keys, database passwords and third-party tokens end up in environment variables, in the deployment bundle, or logged to the platform’s log stream. Anyone who can read the function configuration or the logs then reads the secrets, and in serverless that surface is often broader than teams expect, since configuration and logs are readable by more identities than a traditional server ever exposed.

Each function ships its own bundle of libraries, and those bundles rot. A known-vulnerable package in a function that handles attacker-influenced input is directly exploitable. We inventory dependencies across your functions and identify the ones that are both outdated and reachable.

A server-side request forgery flaw in a function can be turned toward the cloud metadata service or internal endpoints to steal the function’s credentials and pivot deeper. We test outbound-request handling wherever a function fetches a URL on someone else’s behalf.

In a distributed function architecture, each function tends to assume that whatever invoked it already checked the caller. Often nothing did. We test whether an internal function can be reached directly, whether one user’s request can trigger an action on another’s data, and whether the authorization decision is enforced consistently rather than left to whichever function happened to run first.

Serverless bills by invocation, so an attacker who can trigger a function in a loop can run up a large bill or exhaust concurrency and take the application down. We check for invocation limits, throttling and cost controls, an abuse class that only exists because of the pay-per-use model.

SOC 2 and ISO 27001 both expect independent testing of the application and its environment, and ISO 27001 A.12.6 on vulnerability management maps to this work. We assess configuration against the CIS Benchmarks for AWS, Azure and GCP and against the provider’s own well-architected security guidance, so the findings sit in a framework your auditor already recognises.

We reference the OWASP Serverless Top 10, which reframes familiar risks for the function model, alongside the OWASP API Security Top 10 for your HTTP entry points. These give your developers a shared, documented basis for each fix.

Where the functions process personal data we test with GDPR in mind, and for regulated financial workloads the results support DORA operational-resilience and third-party testing expectations across the EU.