Android Secrets and Credential Security

Hardcoded secrets are sensitive values embedded directly in application
code, resources, configuration files, or other application artifacts.

Examples of Sensitive Secrets:
Sensitive values may include API keys, passwords, authentication tokens,
private keys, cryptographic keys, client secrets, access tokens, and
other credentials.

Hardcoded Secrets:
Secrets embedded in an Android application can potentially be extracted
through reverse engineering, APK inspection, static analysis, or runtime
instrumentation.

API Keys:
API keys embedded in an application should be treated as potentially
exposed because an attacker who obtains the APK may be able to extract
them.

Passwords:
Hardcoded passwords can be extracted from application artifacts and
should not normally be embedded directly in application code.

Authentication Tokens:
Hardcoded authentication tokens may allow unauthorized access if the
token remains valid and provides meaningful privileges.

Cryptographic Keys:
Hardcoded cryptographic keys can potentially be extracted and used to
decrypt protected data or impersonate the application depending on
their purpose.

Private Keys:
Private keys embedded in an application are particularly sensitive.
If an attacker can extract a private key, they may be able to
impersonate the application or decrypt/sign data depending on how the
key is used.

Suspicious Strings:
Suspicious strings identified by static analysis should be treated as
indicators requiring further investigation. A suspicious-looking string
is not automatically a secret.

Secret Classification:
The secret_type, pattern, value, and location can help determine whether
a detected string is actually a credential or another sensitive value.

Static Evidence:
A hardcoded secret detected in the APK provides evidence that a
potentially sensitive value is embedded in the application.

Dynamic Evidence:
Runtime logging or instrumentation may reveal sensitive values during
execution. A secret appearing in logcat or runtime hooks may indicate
additional exposure.

Logging Secrets:
Sensitive values written to application logs may be accessible through
debugging mechanisms, compromised devices, or other logging access paths.
Applications should avoid logging credentials and other sensitive data.

Secret Exposure:
The presence of a secret does not always establish the same severity.
The type of secret, its privileges, whether it is still valid, and how
it can be used should be considered.

Important:
Do not classify every suspicious string as a vulnerability. The evidence
should indicate that the value is actually sensitive or potentially
usable as a credential.

Confidence:
A secret detected through multiple independent sources, such as static
analysis and runtime observation, provides stronger evidence than a
single heuristic match.