© 2026 Clermont Oakson LLC

# Article list

  1. Google Private API
  2. The Stack system
  3. CVE-2024-38063 - Remote over TCP/IP
  4. Buffer overflow and overread in Phar PHP
  5. MFA in Today's Cybersecurity Landscape.
Home / Google Private API

Google Private API

Breaking the Blackbox


Exploring Google’s API Ecosystem: A White-Box Approach

When dealing with Google’s vast infrastructure, the challenge lies in uncovering hidden endpoints and parameters that may still exist from development or testing phases. These overlooked elements often present opportunities for security vulnerabilities. The goal is to transform Google’s ecosystem from an opaque "black box" into a transparent "white box."

Understanding Discovery Documents

Google provides machine-readable documents, similar to OpenAPI specifications, called discovery documents. These are designed to outline API methods for public services like the YouTube Data API. Interestingly, these documents also exist for private APIs, such as the Internal People API.

For instance, attempting to fetch the discovery document for the Takeout Private API without proper credentials results in:

http
GET /$discovery/rest Host: takeout-pa.googleapis.com

Response:

json
{ "error": { "code": 403, "message": "Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.", "status": "PERMISSION_DENIED" } }

However, by leveraging Google’s authentication mechanisms, it’s possible to bypass such restrictions.

Web-Based Google Authentication

When examining requests made by Google services, such as the Internal People API used by Google Chat, you’ll notice headers like X-Goog-Api-Key and SAPISIDHASH. These values authenticate requests and provide access to specific endpoints.

Example request:

http
POST /$rpc/google.internal.people.v2.minimal.InternalPeopleMinimalService/GetPeople HTTP/2 Host: people-pa.clients6.google.com X-Goog-Api-Key: AIzaSyB0RaagJhe9JF2mKDpMml645yslHfLI8iA Authorization: SAPISIDHASH <redacted> Content-Type: application/json+protobuf

The X-Goog-Api-Key ties the request to a specific Google Cloud project. If this key lacks permissions for a particular API, you’ll encounter errors like:

json
{ "error": { "code": 403, "message": "Play Atoms Private API has not been used in project 576267593750 before or it is disabled." } }

However, staging environments often have more lenient access controls. For example:

http
GET /$discovery/rest Host: staging-people-pa.sandbox.googleapis.com Referer: https://chat.google.com X-Goog-Api-Key: AIzaSyB0RaagJhe9JF2mKDpMml645yslHfLI8iA

This may reveal internal documentation that includes comments and implementation details.

Authentication on Android Devices

On Android, authentication operates differently. Instead of cookies, bearer tokens derived from refresh tokens are used. These tokens inherit permissions based on the app requesting them.

To generate an Android refresh token:

http
POST /auth Host: android.googleapis.com Content-Type: application/x-www-form-urlencoded androidId=fb213fefa471dcde&Token=<oauth_token>&service=ac2dm&callerPkg=com.google.android.gms&add_account=1&callerSig=38918a453d07199354f8b19af05ec6562ced5788

The response includes a token that can be used to authenticate further requests:

text
Token=aas_et/<redacted> Email=testuser@example.com

By using this token, you can generate bearer tokens tied to specific app contexts.

Transcoding Protocols and Error-Based Discovery

Google APIs often support multiple formats like JSON and Protocol Buffers (protobuf). Sending malformed payloads can reveal parameter types and structures. For example:

http
POST /youtubei/v1/browse HTTP/2 Host: youtubei.googleapis.com Content-Type: application/json+protobuf [1, true, "test"]

The response might indicate expected types:

json
{ "error": { "message": "Invalid value at 'browse_id' (TYPE_STRING), true" } }

This technique can be extended to reconstruct undocumented request schemas.

Leveraging Visibility Labels

Some APIs are hidden behind visibility labels that require specific parameters to access. For example:

http
GET /$discovery/rest?labels=PANTHEON HTTP/2 Host: servicemanagement.googleapis.com X-Goog-Api-Key: AIzaSyCI-zsRP85UVOi0DjtiCwWBwQ1djDy741g

Adding labels=PANTHEON reveals additional documentation not visible otherwise.

Automating Discovery

To simplify these processes, tools like req2proto can automate schema reconstruction by iterating through parameter types and nested messages. This allows researchers to map out undocumented endpoints efficiently.

Example usage:

bash
$ ./req2proto -X POST -u https://youtubei.googleapis.com/youtubei/v1/browse -p youtube.api.pfiinnertube.GetBrowseRequest -o output -d 3 -v

The output provides a complete protobuf schema for the targeted endpoint.


By combining these techniques—discovery document exploration, authentication manipulation, and error-based schema inference—you can gain deeper insights into Google’s private APIs.