Level 2
Lesson learned
Whereas EC2 instances obtain the credentials for their IAM roles from the metadata service at 169.254.169.254 (as you learned in flaws.cloud Level 5), AWS Lambda obtains those credentials from environmental variables. Often developers will dump environmental variables when error conditions occur in order to help them debug problems. This is dangerous as sensitive information can sometimes be found in environmental variables.
Another problem is the IAM role had privilieges to list the contents of a bucket which wasn't needed for its operation. Best practice is to follow a Least Privilege strategy by giving services only the minimal privileges in their IAM policies that they need to accomplish their purpose. AWS CloudTrail logs can help identify past usage (leveraged by Duo Security's CloudTracker) or AWS Access Advisor (leveraged by Netflix's RepoKid).
Finally, you shouldn't rely on input validation to happen only on the client side or at some point upstream from your code. AWS applications, especially serverless, are composed of many building blocks all chained together. Developers sometimes assume that something upstream has already performed input validation. In this case, the client data was validated by Javascript which could be bypasseed, which then passed into API Gateway and finally to the Lambda. Applications are often more complex than that, and these architectures can change over time, possibly breaking assumptions about where validation is supposed to occur.
Level 2 challenge
This next level is running as a container at http://container.target.flaws2.cloud/. Just like S3 buckets, other resources on AWS can have open permissions. I'll give you a hint that the ECR (Elastic Container Registry) is named "level2".