Firebase Config and API Keys: Public Identifiers vs Real Access Controls

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.

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.