Leaked Firebase Cloud Messaging Server Key: what to do in the first hour

• Backend configuration. A push sender in a server, a queue worker or a cron job with the key set as a constant, committed with the rest of the code.
• Mobile build settings. A key copied into a configuration file or a build script that was published to a public repository.
• Tutorials and samples. A copied sample that calls the send endpoint with a real key left in place.
• Environment files. A .env file or a CI variable export printed into logs during a debug step.
• Shared code. A helper script sent to a colleague or posted to a forum with the key still inside.

1. Check which kind of key it is. Look at the project in the Firebase console and see whether the value is a legacy server key or another credential. Note the project, because a key only sends to devices registered with that project.
2. Move your senders to a service account first. Create or use a service account with the messaging role, store its private key in your secret manager, and send a test notification to a device you control. Google’s current send API uses service-account credentials, not the server key.
3. Retire the exposed key. Use the steps in the Firebase revoke section below. If the console no longer offers a way to remove the legacy key, stop every system that uses it and confirm that sends with it fail.
4. Review recent sends. Look at the messaging reports and the logs of your sending service for the period since the exposure. Look for notifications you did not trigger, unusual volume, and titles or links that do not match your product.
5. Warn your users if pushes were abused. If a fake notification reached them, tell them through a channel you trust, and explain what the real notifications look like.
6. Check the other credentials in the same file. Service account keys, API keys and app secrets that sat next to the server key should be rotated too.
7. Clean the repository. Remove the value from the working tree and rewrite history if the repository is public. See I accidentally pushed an API key to GitHub.

Not sure what else leaked? Run a free scan.

Open the Firebase console, choose the project, and go to the project settings. The Cloud Messaging section lists the server keys and sender IDs for that project. For a legacy key, check whether the console still offers a way to delete or disable it. If it does not, the reliable steps are to stop using the key everywhere, confirm that sends with it fail, and turn off the legacy messaging API in the Google Cloud console for that project. Google has been retiring the legacy send API, so if the page differs from this description, follow Firebase’s current documentation on migrating to HTTP v1 and removing legacy credentials.

The rule is called “Firebase Cloud Messaging Server Key”. It looks for a word boundary, the literal prefix AAAA, seven letters, digits, underscores or hyphens, a colon, and then exactly 140 of the same characters, followed by a word boundary. There is no context keyword, so the match depends on the structure alone. A value with a shorter body after the colon does not match, and a web API key starting with AIza is a different rule. The severity is high. This type is not checked live: LeakWatch does not send any request to Firebase with the key it found, so a hit shows that the value has the expected shape and not that it still works. The 140-character length comes from the observed format of legacy keys and should be read as an approximation.