Classify the value before reacting
The Firebase API-key guidance explains the role of Firebase client keys. A service-account private key, backend credential or third-party privileged API key is a different category and must not be shipped in a client.
| Value | Review focus |
|---|---|
| Firebase client configuration | Correct project, restrictions and product controls |
| Service-account private key | Remove from client and rotate if exposed |
| Third-party API key | Publisher permissions, restrictions and billing risk |
| User access token | Expiry, scope, storage and leakage |
Check the actual access boundary
Use Firebase Security Rules and appropriate server authorization for the product. A hidden project ID cannot compensate for publicly writable data.
Test an unauthenticated request, an authorized user's request and a user requesting another user's resource. Those reveal more than whether a config string is visible.
Review restrictions carefully
Apply supported application/API restrictions according to Firebase's current guidance and the APIs the app uses. An overly broad key can expose unnecessary API usage; an incompatible restriction can break legitimate initialization or sign-in.
Do not rotate a client key blindly without planning rollout and checking which released app versions depend on it.
Keep configuration and secrets separate
Use environment-specific app registrations and avoid mixing production and staging endpoints. Do not add privileged credentials to google-services.json or a similarly named custom file because it appears to be “configuration.”
Use scanning to prioritize investigation
APKLint's Firebase Config Scanner can identify packaged values and help inventory potential exposure. It cannot determine private backend permissions from the key alone. Label findings precisely: public identifier, potentially privileged credential, or confirmed excessive access based on an authorized test.
Write a precise finding for a visible client key
Imagine an APK inspection finds a Firebase client API key and project ID in packaged resources. Record that these identifiers are present and identify the Firebase project they configure, using only an authorized environment. Do not label the application compromised solely because a client configuration value is readable. Firebase's API-key guidance explains the client key's role and the separate need for restrictions and product access controls.
Next establish what an unauthenticated request can actually do in your own test project. If private database records are readable, the actionable issue is the authorization configuration and its demonstrated effect. If access is correctly denied, preserve that negative result rather than manufacturing an exposure claim from the identifier alone. Other APIs enabled for the same key can have their own usage and billing implications, so review the key's allowed services as a separate boundary.
Handle a genuinely privileged credential differently
A service-account private key packaged inside the app is a different finding. Identify the affected credential and its privileges, revoke or rotate it through the authorized process, remove it from distributed client material and review its use. Moving it from a JSON file to an obfuscated string does not restore secrecy because the client still needs the value. The server-side operation should use a controlled backend identity with appropriate authorization.
When changing client-key restrictions, test the exact APIs and released app identities that depend on the key. An overly restrictive change can interrupt legitimate sign-in or service initialization. Preserve an inventory of supported variants and certificate identities so a restriction is based on actual distribution paths.
Keep the final report concrete: value category, affected artifact, authorized test, observed access and recommended control. Exclude full user tokens, private keys and unnecessary account data from screenshots or logs. If the evidence establishes only a public identifier, say so. If it establishes excessive access, describe the operation and affected resource scope. This distinction makes scanning useful for remediation instead of treating every recognizable key-shaped string as the same security defect.
Sources and further reading
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
