fix: validate universe domain input to prevent SSRF credential leak

[adilburaksen]

Summary

The universe input in upload-cloud-storage (and deploy-cloud-functions) is interpolated directly into the GCS/Cloud Functions API endpoint without validation:

// @google-cloud/storage SDK (storage.ts:728)
let apiEndpoint = `https://storage.${universe}`;

Setting universe: attacker.com routes all API requests — including the Bearer GCP access token — to storage.attacker.com.

Fix

Validates universe against a strict allowlist: the public Google Cloud universe (googleapis.com) or Trusted Partner Cloud subdomains (e.g. us-central1.rep.googleapis.com).

if (!/^([a-z0-9-]+\.)*googleapis\.com$/.test(universe)) {
  throw new Error(`Invalid universe domain "${universe}": ...`);
}

Tests Added

• Rejects attacker.com → Invalid universe domain error
• Rejects attacker.com#.googleapis.com (fragment injection) → error
• Accepts us-central1.rep.googleapis.com (valid TPC universe) → no validation error

Related

Companion fix for get-secretmanager-secrets (same SSRF class): google-github-actions/get-secretmanager-secrets#328

[adilburaksen]

Updated this PR based on further review:

• The validation now checks that universe is a well-formed DNS hostname (no scheme, path, port, userinfo, query, or fragment) rather than allowlisting *.googleapis.com. The earlier allowlist would have broken non-googleapis.com Trusted Partner Cloud / Google Distributed Cloud universes — this revision is non-breaking while still blocking the credential-leak vector (e.g. attacker.com# truncating the real host).
• Rebased onto current main.
• Tests cover injection payloads (#, /, :, @, ://, embedded whitespace) and legitimate universes (googleapis.com, us-central1.rep.googleapis.com, apis-tpc.goog). Lint clean.

Happy to address any review feedback.

[adilburaksen]

@verbanicm friendly ping — would you be able to take a look at this one? It validates the universe input against the googleapis.com domain pattern before it's used to build the API endpoint, so a workflow can't be steered into sending the GCP access token to an arbitrary host. CI is green. The companion action has the same fix in deploy-cloud-functions#472 (same root cause). Happy to adjust the allowlist pattern however you prefer.

[adilburaksen]

@R2wenD2 @haroonc — gentle follow-up. This validates the universe input against the googleapis.com domain pattern before the endpoint is built, closing the case where a crafted universe (containing #/?) routes the request — with the GCP access token — to an attacker-controlled host. Mergeable, green, with 4 added test cases; the companion fix is deploy-cloud-functions #472. Could you take a look when you have a moment? Happy to adjust the approach per your preference.