How to Test Serverless Application Attack Surfaces

TL;DR

Enumerate every serverless endpoint, verify its access permissions, tamper with call data, and test whether limited access can be upgraded to administrator privileges. Pay particular attention to protected pre-authentication functions, client-side configuration, Cognito identity pool identifiers, cloud storage, and peer development infrastructure because generated frameworks can conceal security behavior and expose remotely callable components.

Transcript

Uh, title of this talk is called Red Team View: Gaps in the Serverless Attack Surface. Uh, my name is Michael Cotton. I'm the SVP of Research and Development at Digital Defense Incorporated. And, uh, uh, so let's go into it. So, um, you know, just giving a quick overview. So, you know, serverless really is another major phase of the web, you know? ... Read More

Key Insights

• Serverless computing is a major architectural shift because application code runs on another party's infrastructure, making carefully configured permissions and access restrictions central to security rather than leaving developers with a familiar server-centered workflow.
• The serverless attack surface includes API endpoints, Lambda or cloud functions, cloud storage, databases, identity services, and peer development infrastructure. Assessing only the visible website can therefore miss remotely accessible components and supporting systems.
• Modern client-side JavaScript applications expose APIs as remote interfaces rather than keeping them behind server-rendered views. Rapid endpoint enumeration and permission testing are consequently core activities when assessing serverless web and mobile applications.
• Generated serverless projects can hide significant complexity. A React Hello World project with AWS Amplify SDKs can contain 33,000 files, mostly node modules, and still contain 85 files outside node modules, so assessors must understand automated security configuration.
• Public functions are callable without sign-in protections by posting the expected data, including JSON, with tools such as Curl. Their explicit exposure and absence of authentication make careful review of accepted input and accessible resources necessary.
• Protected functions use HMAC SHA-256 signing with a client token obtained through Cognito, but they can operate before user authentication. The protected label therefore does not establish a known authenticated identity and deserves close examination during remote enumeration.
• Private functions are intended for post-authentication access and may have additional limits on database access. Their stronger classification does not eliminate risk, so assessors should still inspect authorization boundaries, data access, and opportunities for privilege escalation.
• The central assessment method is to enumerate endpoints, check access permissions, tamper with data in calls, and determine whether access can be obtained or upgraded to administrator privileges. The same method supports both penetration testing and defensive hardening.

Questions & Answers

Q: How do you test a serverless application attack surface?

Begin by enumerating the application's remote endpoints and identifying associated Lambda or cloud functions, cloud storage, identity services, databases, and peer development infrastructure. Determine whether each function is public, protected, or private, then verify the actual access controls. Tamper with data in requests and test whether unauthenticated or limited access can be converted into administrator-privileged access.

Q: Why are serverless applications difficult to secure?

Serverless applications place code on cloud infrastructure and rely on developers to configure permissions and access restrictions correctly across multiple component services. Modern frameworks also generate substantial boilerplate and configuration automatically. Because much of this behavior remains beneath the visible application, a setting described as protected or private may provide narrower safeguards than developers expect unless its exact behavior is understood and tested.

Q: What should red teams enumerate in a serverless application?

Red teams should enumerate API endpoints, Lambda or cloud functions, cloud storage services, identity components such as Cognito, databases, and peer development infrastructure. They should also inspect requests generated by web and mobile clients before and after authentication. Each discovered component should be mapped to its access classification, accepted data, reachable resources, and potential role in obtaining or escalating privileges.

Q: What is the difference between public, protected, and private functions?

Public functions can be reached without sign-in protections by posting the required data. Protected functions add HMAC SHA-256 signing through a client token obtained from Cognito, but they can still be available before authentication, when the application does not yet know the user's identity. Private functions are post-authentication and may also have additional restrictions on the database resources they can access.

Q: Why should protected serverless functions receive extra scrutiny?

Protected functions deserve scrutiny because their label can imply stronger identity controls than they actually provide. The described protection uses HMAC SHA-256 signing with a client token from Cognito, yet the function may remain accessible before authentication. Since the application does not know who its users are at that stage, assessors should closely test permissions, inputs, and accessible resources.

Q: How can client-side traffic reveal serverless components?

Opening an application without stored cookies and observing its initial traffic can reveal calls made before login. The example shows several requests to Cognito and exposes an identity pool ID as a typically hard-coded component. JavaScript applications and native mobile apps communicate directly with remote web endpoints, so debugging their network behavior helps identify functions and identity infrastructure for further permission testing.

Q: Why do generated serverless projects create security risk?

Generated projects can perform extensive setup without making every security consequence obvious to the developer. The example React Hello World application with AWS Amplify SDKs contains 33,000 files, largely because of node modules, plus 85 files outside node modules. Automation reduces boilerplate work, but teams must still determine which protections were created, what they cover, and where their limitations remain.

Q: How can developers and DevOps teams harden serverless applications?

Developers and DevOps teams should inventory every endpoint and supporting service, verify actual permission behavior, and avoid relying solely on labels such as protected or private. They should review pre-authentication access, restrict what functions can reach in databases and storage, inspect automatically generated configuration, test request tampering, and ensure ordinary users cannot upgrade their access to administrator privileges.

Summary & Key Takeaways

• Serverless applications represent a significant architectural shift because developers send code to cloud infrastructure and depend heavily on correctly configured permissions and access restrictions. The resulting attack surface includes API endpoints, Lambda or cloud functions, client applications, cloud storage, identity services, databases, and related development infrastructure that may expose additional paths.

• A practical assessment begins by rapidly enumerating remotely accessible endpoints, determining whether each endpoint is public, protected, or private, and verifying what those labels enforce. Testers should inspect client-side traffic and configuration, evaluate pre-authentication Cognito interactions, modify data passed in calls, and investigate whether ordinary access can be elevated to administrator privileges.

• Generated application stacks can contain thousands of files and perform substantial configuration automatically. Convenience does not guarantee comprehensive security controls. Red teams, developers, DevOps teams, and defenders therefore need to understand what frameworks create, identify the limitations of default protections, and apply stronger authorization restrictions to functions, databases, storage, and supporting services.