Apps with embedded credential findings

What this category covers

This is the hub for every finding where a credential-shaped value was found compiled into an app: API keys, access tokens, private key material, service-account JSON, database credentials, signing secrets.

We have recorded at least one in 5,605 apps. That figure is large because the category is broad and because a great many of the values involved are meant to ship.

Not every key in an APK is a leak

Anything an app sends to a service has to be inside the app, so the useful question is never whether a key is present but whether its exposure matters. Three cases behave completely differently. A client key designed to be public, such as a Maps key or a Firebase web config, is safe when it is correctly restricted and useless to restrict by hiding. A scoped server token is a real leak, revocable, and the remediation is to rotate it. Private key material or a service-account credential is the serious case, because it often grants more than the app itself needed.

The largest source of noise is library code. A test key compiled into every app that links a particular TLS library is not that app's secret, and documentation examples travel the same way. We handle this corpus-wide: a value appearing under three or more unrelated developers is reported as a library artifact rather than counted against any one app. That rule alone moved a substantial number of apps off failing grades, and it exists because the alternative was publishing findings that were true about a string and false about the app.

How to act on one

• Classify before reacting. Decide which of the three cases a value falls into, since the correct response differs completely.
• Rotate anything in the second or third case and treat it as public from the moment it shipped. No amount of obfuscation changes that.
• Restrict what is meant to be public: bind client keys to your package name and signing certificate and to the specific APIs they call.
• Remove server credentials from the client entirely and put a service you control in front of them.
• Check your history as well as your current build. A key removed in this release is still in the previous APK, which people can still download.

What we store, and what we never store

The value is never kept. What is recorded is a scheme prefix, a coarse length bucket and a non-reversible fingerprint — enough to deduplicate a finding and to recognise the same artifact across different apps, and not enough to reconstruct the secret from anything we publish or export.

We also do not test whether a credential works. Using a key found in someone else's app to authenticate to a service would be the most direct way to prove a finding, and it is not something we will do. Where a check is possible without any credential at all — asking whether a storage bucket answers an anonymous caller — we do that instead, and record it.