A YouTube auth check nobody wrote leaked private videos to anyone

What happened

A security researcher writing at javoriuski.com walked through a chain of small, boring bugs that added up to something Google would rather not have shipped: the ability to pull the video stream URL for any private or unlisted YouTube video, given only the video ID. No account takeover. No malware. No exotic side channel. Just a poorly scoped internal API and an obscure product surface that leaked Google account IDs.

The chain, in rough shape: an internal-looking YouTube endpoint accepted a request for a video's playback manifest and returned the signed CDN URLs, but only performed a lightweight authorization check that assumed the caller was either the owner or a viewer with explicit access. The check was scoped by Google account ID rather than by session — meaning if you knew the owner's account ID, you could ask on their behalf. The account ID, which Google treats as a semi-secret internal identifier, turned out to be recoverable from a second, entirely unrelated product surface that exposed it in an API response. Chain the two and the private-video protection collapses to "do you know the uploader's numeric ID," which is not a security boundary — it's a lookup.

Google patched it after disclosure and paid a bounty. The write-up landed on Hacker News, hit the front page with 604 points, and the top comments read exactly like you'd expect: a lot of "how is this still 2024's auth failure mode" and a lot of engineers quietly recognizing the pattern from their own systems.

Why it matters

The temptation with a story like this is to file it under "lol Google" and move on. Don't. The interesting part isn't that a bug existed at Google — it's that the bug is structurally identical to bugs sitting in almost every large service you've ever worked on.

Every big company has internal APIs. Those APIs get built under the assumption that the caller is trusted — a first-party client, an internal microservice, an employee tool. The authorization logic gets written to match: "the caller says they're acting on behalf of user 12345, so check if user 12345 has access." That works when the network topology guarantees the caller identity. It stops working the second the endpoint is reachable from the outside, even indirectly through a proxy, a mobile client, or a partner integration. And the failure mode is silent: the endpoint keeps returning correct answers to legitimate callers, so nobody notices until a researcher pokes it.

The second half of the chain — the account-ID leak — is the other lesson. Identifiers that are treated as public in one product become secrets when they're used as auth material in another. This is the same class of bug as [IDOR](https://owasp.org/www-community/attacks/Insecure_Direct_Object_Reference) with extra steps: the ID isn't guessable, but it's discoverable, and once it's discoverable the "unguessable ID" defense becomes zero-factor auth. Google Groups, Google Photos album shares, YouTube playlists, Docs share links — all of them have historically leaked identifiers in ways that felt harmless because the identifier wasn't marketed as a credential. This bug is what happens when a downstream team treats one of those leaked identifiers *as* a credential.

The Hacker News thread is a graveyard of people naming their own version of this bug: "we had this exact pattern with S3 signed URLs," "we had this with tenant IDs in the JWT," "we had this with a customer number that turned out to be sequential." The common thread is engineering culture — specifically, the moment where a team ships an internal API and the auth review says "it's internal, we're fine," and nobody comes back to re-review when the network shape changes six quarters later.

Worth naming the elephant: bug bounties caught this. Google's VRP paid out, the researcher published, the hole is closed. That's the system working. But it's also a reminder that the researcher pipeline is doing load-bearing work that internal red teams and design review are supposed to do, and at every company smaller than Google, that pipeline is thinner.

What this means for your stack

Three concrete things worth doing this week if you own a service with a private/shared/unlisted primitive:

First, audit every endpoint that takes a user ID or account ID as a parameter and treats it as the auth subject. The right pattern is: the session determines who the caller is, and the caller can only ask about resources they own or have been granted. If your endpoint takes `?user_id=X` and returns anything about user X, the endpoint is one misconfigured gateway away from being this bug. The fix is boring: derive the user from the session, not the request body.

Second, treat every identifier that appears in an API response as public. If your auth model has any dependency on an identifier being "hard to find," write down which identifier and where it's exposed. The exercise is almost always embarrassing. Account IDs, tenant IDs, internal customer numbers, invite tokens that never expire, S3 keys with predictable prefixes — all of these show up in logs, in referrer headers, in support tickets, in mobile app bundles. If knowing the ID grants access, the ID is a password, and it's a password you're printing in your own responses.

Third, re-run auth review whenever the network shape changes. The classic trigger is "we moved this service behind a public gateway," but the subtler triggers are worse: a new mobile client, a partner integration, a debugging endpoint that got left enabled, a CDN configuration change that started forwarding a header the origin never expected. A one-page checklist that gets triggered by network-boundary changes catches most of these. Nobody has one. Write one.

For teams shipping video, file storage, or any "share by link" primitive specifically: the signed-URL pattern is only as strong as the endpoint that mints the signed URL. If the minting endpoint has weak auth, the signature is theater. Log every mint. Alert on mint rate anomalies per account. Rotate the signing key when you find a bug in the minter, not just when you find a leaked URL.

Looking ahead

The interesting product question is whether Google — and every platform with a similar primitive — will start treating private/unlisted as a stronger promise than "we won't link to it." Unlisted has always been the weakest tier, defended by URL obscurity; private is supposed to be the real thing. This bug blurred the line. Expect quiet tightening across the industry: per-viewer signed manifests, session-bound playback tokens, faster manifest expiry, and — for the paranoid — a nudge toward age-gated or account-gated content requiring explicit share grants instead of "anyone with the link." The security lesson is old. The product lesson is that "share by link" is a UX bet that your auth stack is bulletproof, and this month it wasn't.