Hardcoded API Keys in APKs: Separate Public Identifiers from Secrets

Classify before reacting

Firebase explains that its client API keys are generally identifiers rather than authorization secrets. That does not make every Google Cloud API key harmless or replace Firebase Security Rules and other access controls.

Inspect the capability, not the label

For each detected value, record its source file, owning service, allowed APIs, application restrictions and revocation process. Redact the value in tickets. Do not “test” a discovered third-party credential against services you are not authorized to access.

For your own exposed secret, revoke or rotate it through the provider and review access logs. Removing the string from the next release does not invalidate copies of an already distributed APK.

Keep privileged operations on the server

A mobile client is distributed to users and can be inspected. Do not embed a backend administrator key and rely on obfuscation to keep it secret. Use authenticated, narrowly authorized server operations instead.

Build-time secret injection prevents accidental repository commits, but it does not make a value confidential once compiled into the client. The Secrets Gradle Plugin helps manage local configuration; it is not an encryption boundary around distributed credentials.

Verify the release and restrictions

Inspect the final package, including assets and generated resources. Check the actual service-side restrictions using a controlled test app or environment. Make sure debug and release signing fingerprints are handled correctly where the provider uses them.

Use scanner output responsibly

APKLint's security tools can surface key-like strings and risky configuration. Treat those as leads. A finding needs service context before it can be labeled a credential leak, and a scan without matches cannot prove that all secrets are absent or that backend access controls are correct.