A Google OAuth client secret, used together with its client ID, identifies your application to Google when it exchanges sign-in codes for tokens. Whoever holds the secret can take part in that exchange as your app, and the secret stays valid until someone replaces it by hand. It does not unlock your users’ accounts on its own, because an attacker also needs an authorization code or a redirect to a server they control. Still, the secret is cheap to replace and expensive to leave exposed. Replace it, then check your project’s logs.
Check your GitHub account for leaked secrets — free
- Provider
- Google Cloud
- Severity
- Critical
- Impact
- Source code and build access
- Checked live by LeakWatch
- No
What a Google OAuth Client Secret looks like
A Google OAuth client secret starts with the fixed prefix GOCSPX-, followed by a fixed number of letters, digits, underscores and hyphens. You see it in the client’s details in the Google Cloud console, and it usually sits in a JSON file you downloaded when you created the client:
GOCSPX-…XXXX Google OAuth client secret (masked)
The client ID next to it ends in .apps.googleusercontent.com. The client ID is public by design and appears in front-end code, so it is not the problem. The prefix is distinctive, so a hit rarely needs any other context. Other Google credentials look different: a service account key is a JSON file containing a private key, and a Google API key starts with AIza.
How Google OAuth Client Secrets get leaked
- Downloaded client files. The JSON file for the client, committed with the rest of the project.
- Environment files. A
.envfile or framework configuration for a web app that defines the client secret next to a public client ID. - Compiled or shared configuration. Mobile and desktop projects where the secret was built into the app or stored in a shared configuration file.
- Sample code. Tutorials and starter projects copied with the real values still filled in.
- CI logs. A failed sign-in test that prints the whole configuration to the log.
What to do in the first hour
- Open the client in the console. In the Google Cloud console, go to APIs & Services, then Credentials, and open the OAuth 2.0 client that owns the leaked secret. Match it by its client ID if you are not sure which client the file belonged to.
- Add a new secret. The client’s details let you add a new secret while the old one still works. Google allows more than one secret per client at a time, so you can switch without downtime.
- Deploy the new secret to your application, then test a sign-in in each environment that uses this client.
- Disable and then delete the old secret. Disabling first lets you undo the change if something still depends on the old value. Delete it once the new one is confirmed.
- Review the project logs. Open the Cloud Audit Logs for the project and look for changes since the exposure: new or edited OAuth clients, changes to the consent screen and new projects. Pay attention to redirect addresses. An attacker who adds one can send sign-in codes to a server they control.
- Check your own sign-in records. Look in your application’s logs for sign-ins from unexpected places, and for users who report prompts they did not expect.
- Clean the repository. See I accidentally pushed an API key to GitHub, and use deep scan your whole git history to find older copies.
Not sure what else leaked? Run a free scan.
Revoke it at Google Cloud
Open the Credentials page in the Google Cloud console, select the project that owns the client, and open the OAuth 2.0 client. Add a new secret there, deploy it, and then use the console’s option to disable the old secret and delete it once nothing depends on it. Check the project picker first, because each client belongs to one project and a client missing from the list is in another. Disabling the old secret is what stops it from working.
How LeakWatch detects it
The rule is called Google OAuth Client Secret. It looks for the exact prefix GOCSPX- followed by exactly 28 letters, digits, underscores or hyphens, with a word boundary on each side. No context word is needed, because the prefix is distinctive. A value with fewer or more characters after the prefix is not reported, since that does not match the format Google uses. The severity is critical, because a client secret stays valid until someone replaces it by hand. This type is not checked live: LeakWatch does not contact Google with the secret it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Can someone sign in to my app as my users with this secret?
Not by itself. The secret proves your app’s identity to Google during a token exchange. An attacker also needs a valid authorization code, which comes from a user’s consent, or control of a redirect address you allow. Replace the secret anyway, because it is cheap to fix.
Do I need to rotate the client ID too?
Usually not. The client ID is public by design. Rotate the secret, then review the client’s redirect addresses and who has access to the project.
Why is the severity critical if access tokens expire?
The access tokens your app gets from Google expire within about an hour. A client secret does not expire on its own. It stays valid until someone replaces it, which is why an exposed secret is more dangerous than an exposed short-lived token.