The article describes a novel attack vector leveraging AI to automate the fuzzing of Google's internal APIs using publicly accessible discovery documents. The method involved systematically harvesting API keys from Google's own applications and services, then using those keys to access and test a wide range of internal APIs at scale for vulnerabilities. The research did not disclose a specific CVE, CVSS score, affected versions, or patch details, focusing instead on the proof-of-concept methodology.
After being invited to bugSWAT Mexico in October 2025, I found myself drawn back to Google research. While I'd been focused on other projects for several months, the team's willingness to give researchers a peek into Google's source code reignited my interest in exploring Google's attack surface. Having spent the past year building small projects with Claude, I realized there was untapped potential in using AI to automatically fuzz Google's APIs at scale. The key to this approach? Google's discovery documents. For those unfamiliar, I'd recommend reading my other article for a deep dive, but here's a quick refresher: Discovery documents are essentially Google's equivalent of Swagger docs - machine-readable API specifications that list all available endpoints, parameters, and methods. While they're publicly documented for APIs like the YouTube Data API , they also exist for Google's internal APIs (like the Internal People API). Some discovery docs are publicly accessible , while most require valid API keys . Here's an example from the YouTube Data API's discovery document: ... "liveChatModerators" : { "methods" : { "insert" : { "flatPath" : "youtube/v3/liveChat/moderators" , "description" : "Inserts a new resource into this collection." , "httpMethod" : "POST" , "parameters" : { "part" : { "description" : "The *part* parameter serves two purposes in this operation. It identifies the properties that the write operation will set as well as the properties that the API response returns. Set the parameter value to snippet." , "repeated" : true , "required" : true , "location" : "query" , "type" : "string" } ... # Collecting API Keys To access most discovery documents, you need a valid API key. API keys are embedded in virtually every Google app and service, but crucially, an API key found in one service will often have multiple other APIs enabled for its Google Cloud Platform (GCP) project. This means that collecting as many keys as possible would give us access to numerous Google APIs. For the key collection part, my friend Michael and I teamed up. We took an exhaustive approach. We scraped over 60,000 Android APKs (every version of every Google app ever released), unpacked them, and grepped for API keys. user@siege:/mnt/data/apks$ ls -1 | wc -l 61200 We built a Chrome extension using the Chrome Debugger API to intercept network traffic, then systematically visited all known Google web domains (2.8k+) and used every web app feature possible to capture keys from live requests. We also decrypted every Google IPA we could obtain and analyzed any Google binaries we could find. To keep things in scope for Google VRP and remove non-Google API keys (keys from third-party GCP projects), I used an interesting endpoint I found in the Cloud Marketplace API. First, we need the project number associated with the key's GCP project, which is revealed in the error message returned when using the key with a Google API it doesn't have enabled. For instance, fetching https://protos.googleapis.com/$discovery/rest?key=AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc returns the error: Protos API has not been used in project 244648151629 before , revealing the project number. The Cloud Marketplace endpoint takes this project number and returns information about the project: GET /v1test/infoSharing/test/test/1044708746243 HTTP/2 Host : cloudmarketplace.clients6.google.com Cookie : <redacted> Authorization : <redacted> Origin : https://console.cloud.google.com X-Goog-Api-Key : AIzaSyDWUi9T78xEO-m10evQANR7TMSiB_bjyNc 1044708746243 is the target project number. This responds with the following: HTTP/2 200 OK Content-Type : application/json; charset=UTF-8 { "company" : "google.com" , "email" : "gvrptest2 @gmail .com" , "name" : "GVRP Test2" } The email and name are for my authenticated Google account, but the company is the domain tied to the GCP project number we supplied. Running this endpoint through the GCP projects tied to all the keys allowed for filtering out non-Google API keys, by simply discarding keys not from google.com projects (or other acquisitions e.g nest.com , fitbit.com , wing.com ). With API keys collected, the next step was finding all Google API domains to scan. I used a combination of domains logged by the Chrome extension, brute-force generated names using keywords, and certificate transparency logs . To verify if a domain was a live Google API, I made the following request: GET / HTTP/2 Host : people-pa.googleapis.com Then I would check the Server response header: HTTP/2 404 Not Found Date : Mon, 16 Feb 2026 08:46:31 GMT Content-Type : text/html; charset=UTF-8 Server : ESF If this header existed (usually ESF , GSE , or scaffolding on HTTPServer2 ), then it was a valid Google API service that was alive and responding to requests. # Scanning for Discovery Documents Equipped with valid API keys and a list of live Google API domains, I started mass scanning for open discovery documents. In July 2025, Google removed the /$discov...