Assistance for Project Suspended

Google Cloud Serverless Applications
1

Hi everyone,

I’m posting here because our production project was suddenly suspended by Google Cloud due to “abusive activity consistent with hijacking.”

We fully understand the seriousness of security issues and want to resolve this immediately. However, we received no prior warning, and the suspension notice did not name the specific credential or resource that triggered the action.

We have already submitted an appeal (ticket ID: 4C3KH24DRFM7YVL55JAO76IYEI) but have not yet received a response.

This project powers our live production service used by customers daily. Because of the suspension, the service is currently blocked and our operations are at a standstill while we wait.

Based on the wording of the suspension notice (“credentials or API keys in public sources… harvested… to initiate resources in your project”), we audited our source code and identified the most likely vector: a Google Maps Platform API key that had been committed to a publicly accessible repository and was not locked down with HTTP-referrer / Android-package / iOS-bundle-ID restrictions. Automated scrapers harvest keys like this within minutes of them appearing in public code, and we believe the abusive traffic consisted of billable Maps/Places calls made through the unrestricted key.

We have already started remediation:

  • Removed every hardcoded API key from the current source tree and replaced them with build-time placeholders injected from CI secrets.

  • Added a secret-scanning step to CI that fails any future change which introduces an AIza… key, a service-account JSON, or a BEGIN PRIVATE KEY block.

  • Drafted the rotation plan: regenerate every Maps / Places key in the Cloud Console, apply platform restrictions before saving, and re-issue all client SDK keys.

  • Reviewed IAM and Service Accounts; no service-account private key was ever committed (we verified by scanning the full version-control history).

We are ready to complete the rotation and any further steps Trust & Safety asks for. The suspension is what currently blocks us from finishing — we can’t regenerate keys, audit Billing for unauthorized usage, or delete any unauthorized resources while the project is locked.

Questions for the community / any Googlers reading:

  • Has anyone gone through a “hijacked resources” suspension where the root cause was a leaked client API key (vs. a service-account private key)? Was the appeal response faster once you provided evidence of the vector and the remediation?

  • What was the typical timeline for an appeal response in your case?

  • Is there a recommended way to escalate to the Google Cloud Trust & Safety team for projects running live customer traffic?

  • Once unsuspended, is there a documented best-practice checklist for migrating client API keys to Secret Manager + build-time injection that you’d recommend?

Any guidance is hugely appreciated.

1 Like