Leak of keys and ids. Not critical

Executive Summary

• The shared Firebase plist values are client configuration, not admin credentials.

• With these creds, we can hit some client endpoints, but cannot call admin endpoints or dump users.

• Biggest weakness found: key hardening on Installations looked loose (accepted fake app identity headers in earlier probe).

• Practical risk: low for direct data theft, medium for abuse/quota/cost. Methodics (How We Found It)

• Repo audit using:

  • git status --ignored

  • git check-ignore -v

  • git grep for API key / app IDs

  • git log -S "<value>" to find commits where IDs/keys appeared

  • git blame on exact lines in tracked files

• Live endpoint probing using Python (urllib) with your provided prod client creds:

  • Read-only checks (GET + query POST) for Auth/Firestore/Storage/FCM/Remote Config/RTDB

  • Earlier controlled test also did FIS create/delete installation to validate restrictions (temporary object was deleted) Endpoint Findings (Good vs Not Good)

• Not good / needs tightening

  • POST firebaseinstallations.googleapis.com/.../installations -> 200 even with fake app identity headers (earlier test)

  • Why this matters: key can be abused for high-volume client traffic if not app/API restricted

• Expected/acceptable client access

  • POST identitytoolkit.googleapis.com/v1/accounts:createAuthUri?key=... -> 200

  • POST firebaseremoteconfig.googleapis.com/...:fetch?key=... -> 200 with NO_TEMPLATE

• Good protections (blocked)

  • POST .../relyingparty/downloadAccount?key=... -> 401

  • POST identitytoolkit.googleapis.com/v1/projects/.../accounts:query?key=... -> 401

  • POST firestore.googleapis.com/...:runQuery?key=... -> 403

  • POST firestore.googleapis.com/...:runAggregationQuery?key=... -> 403

  • GET firebasestorage.googleapis.com/.../o -> 403

  • POST fcm.googleapis.com/v1/projects/.../messages:send?key=... -> 401

  • RTDB host probes -> 404 (likely not in use) Git Commit Evidence (IDs/Keys in History)

• Where current tracked values appear

  • desktop/Desktop/Sources/AuthService.swift:74 (API key)

  • desktop/Desktop/Sources/GoogleService-Info.plist:12 (API key)

  • desktop/Desktop/Sources/GoogleService-Info.plist:34 (GOOGLE_APP_ID)

  • desktop/.claude/skills/local-backend-test/SKILL.md:102 (API key in docs)

• Commits introducing/containing these patterns

  • d51d10136 — introduced desktop sources containing Firebase client IDs/keys

  • 5e809e764 — added key into local backend skill doc

  • a704e383f — historical app firebase options added (same ID/key format)

  • e81f1e857 — later removed those historical app firebase option files

  • bb7228634 — iOS Google Sign-In config change (client ID related)

• Gitignore commits relevant to visibility/handling

  • bce15b0e7 — ignored macOS config/google service file paths

  • 2c8e73105 — added ignore for prod macOS GoogleService path

  • d4ba5d850 — added /scripts/ ignore (made scripts easy to hide) Are GOOGLE_APP_ID / client IDs critical secrets?

• GOOGLE_APP_ID: not secret

• PROJECT_ID, GCM_SENDER_ID, BUNDLE_ID: not secret

• Firebase mobile API_KEY: not a server secret, but should be strongly restricted

• OAuth client IDs (iosClientId/androidClientId): not secret

• Truly critical secrets are service-account private keys / backend secrets (none used in these client probes) Security Considerations for You

1. Restrict API keys by exact app identity (iOS bundle, Android package + SHA certs).

2. Restrict each key to only required APIs.

3. Enforce App Check on services you use.

4. Keep strict Firestore/Storage rules (current probes suggest they are working).

5. Add quotas/alerts for Installations/Auth abuse spikes.

6. Remove unnecessary key copies from docs/examples where possible.