Leak of keys and ids. Not critical #5277
Description
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 "" 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
d51d101 — introduced desktop sources containing Firebase client IDs/keys
5e809e7 — added key into local backend skill doc
a704e38 — historical app firebase options added (same ID/key format)
e81f1e8 — later removed those historical app firebase option files
bb72286 — iOS Google Sign-In config change (client ID related)
Gitignore commits relevant to visibility/handling
bce15b0 — ignored macOS config/google service file paths
2c8e731 — added ignore for prod macOS GoogleService path
d4ba5d8 — 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
Restrict API keys by exact app identity (iOS bundle, Android package + SHA certs).
Restrict each key to only required APIs.
Enforce App Check on services you use.
Keep strict Firestore/Storage rules (current probes suggest they are working).
Add quotas/alerts for Installations/Auth abuse spikes.
Remove unnecessary key copies from docs/examples where possible.
This issue is linked to our feedback platform. For more details and updates, please visit this link.