CORSLeak: Stealthy data exfiltration through the use of IAP

Introduction

‍When people talk about “highly restricted” cloud environments, they usually mean environments with no public IPs, no outbound internet, and strict VPC Service Controls locking everything down.

These environments appear virtually impenetrable on paper, with no entry or exit points. However, in this blog, I will demonstrate how a seemingly insignificant configuration in Google Cloud’s Identity-Aware Proxy (IAP) can quietly breach that barrier. By abusing how IAP handles Cross-Origin Resource Sharing (CORS) preflight requests, an attacker can leak data from a locked-down VM to the outside world. There are no socket connections, no exits, just clever behavior from the browser and a carefully crafted header. The objective is to demonstrate the operation of this behavior and the significance of comprehending the interactions between Identity Access Management (IAM), IAP, and CORS. ‍
Defining App Engine, IAP, and CORS

‍
What exactly is a “App Engine”? ‍

Google Cloud’s App Engine platform lets you run your code without managing servers. Google takes care of everything else, including updates, load balancing, scaling, and writing your app. It’s perfect for web apps and APIs, especially if you want something that “just works” without needing to deal with the backend infrastructure.
Since App Engine hides most of the infrastructure, teams frequently distribute roles/appengine.deployer to allow new app versions to be deployed. But that same role also lets them control the HTTP headers served to external users of the app. So now your front-end dev who just needed to tweak some CSS can also exfiltrate data to the outside world. On that, more later. ‍

What exactly is IAP (Identity-Aware Proxy)? ‍

IAP is a Google Cloud service that controls who can access your applications and provides an additional layer of security. Role-based access control (RBAC) is used to control access based on IAM roles and authenticates users with Google Cloud Identity. Only authenticated users with the appropriate IAM roles can access a resource that is protected by IAP, and only through the proxy. IAP can be used to protect various Google Cloud services, including App Engine, Compute Engine, Cloud Run, Google Kubernetes Engine (GKE), and Cloud Functions.
Although App Engine is the focus of this blog, other IAP-protected services like Cloud Run are also susceptible to the attack thanks to the method used.