When you are hunting on a target like Google you are not looking for simple bugs. You are looking for the moments where a massive company chooses convenience over security. After I published the Won't Fix report on the YouTube Music InnerTube API people wanted to know the specific methodology. This is how I identified the Identity Bridge and why it represents a fundamental failure of modern API design.

Phase 1 Challenging the Multi Login Assumption

Most people use Google's account switcher every day without thinking about it. You click a profile and the UI changes. But if you look at the network traffic you notice something suspicious. When you switch accounts the browser does not always drop its session and re authenticate. The SAPISID and other core session cookies often stay exactly the same.

This was my starting point. If the cryptographic session token does not change when I switch from my Work account to my Personal account then the backend must be using a secondary marker to tell them apart. As a researcher that is where you find the gap. You find the marker that the developer thought was safe but is actually user controlled.

Phase 2 Identifying the Weak Marker

I started intercepting every POST request sent to the YouTube Music settings endpoints. That is when I saw the x goog authuser header. It is a simple integer. If you are on your first logged in account it is 0. If you switch to the second it becomes 1.

The technical question was simple. Does the Google backend perform a cross check? Does it verify that the session token in the cookies actually has permission to act as the user ID specified in that header? Or is the backend so focused on speed that it just uses that integer to fetch the data from the database?

Phase 3 The Cross Account Probe

I set up a controlled environment with two accounts. Account 0 was my primary and Account 1 was my target. I kept Account 0 active in my main browser window. Using a script to intercept the fetch call I manually forced the x goog authuser header to 1 while my session was still tied to Account 0.

When the response came back it did not show an error. It did not show a 403 Forbidden. It returned the private settings and configuration for Account 1. This confirmed a Broken Object Level Authorization BOLA. Google was allowing me to bridge the gap between two supposedly isolated identities using a single digit in an untrusted header.

Phase 4 Escalating to Remote Integrity Hijack

A read bug is a problem but a write bug is a crisis. I moved my focus to the set setting endpoint. This is the logic that controls things like Restricted Mode and privacy toggles. I repeated the test. While logged into Account 0 I sent a command to flip the security settings on Account 1.

The server accepted the request immediately. I checked the secondary account and the security state had been modified remotely without any interaction or consent from that account. This was the proof of the Identity Bridge. I had turned a cosmetic account switcher into a remote control for any Google identity associated with the session.

The Reality of the Won't Fix

Google responded by saying this is Working as Intended and Infeasible to fix. That is a heavy admission. It means their multi login system is so deeply integrated into this legacy header logic that they cannot enforce proper authorization without breaking the entire user experience.

For the trillion dollar leader in security to admit that they cannot enforce basic session isolation on their own API is the real story. They have built an architecture where convenience is the priority and security is a secondary consideration. If you are logged into multiple accounts you are not isolated. You are just one header swap away from a total profile leak. If the UI is a cosmetic wrapper and the API is an open bridge then the concept of account isolation at Google is a myth.