M1: Improper Credential Usage
Hardcoded secrets, API keys, and tokens embedded directly in an application binary or source, rather than provisioned at runtime.
Why It Matters
A hardcoded credential is retrievable by anyone who obtains the binary — no privileged access or runtime exploitation required. It is one of the highest-yield findings for an attacker per unit of effort, and one of the most common mistakes in mobile codebases.
Application to Application Security
Covers API keys, backend service credentials, encryption keys, and OAuth client secrets embedded in strings.xml, Info.plist, source literals, or native libraries — anywhere a value is compiled in rather than fetched from a secrets manager or provisioned per install.
Relation to Software Development
Usually introduced for convenience during prototyping and never removed before release, or copied from a backend .env file into client code without recognizing that the client binary is not a trusted execution environment.
How Strata Surfaces This
Regex and entropy-based scanning across binary strings and decompiled source, keyword matching against common credential field names, and git history scanning for credentials that were committed and later removed but remain in history.
Developer guidance
Never compile a secret into client code. Use a secrets manager or a backend-issued, short-lived token fetched at runtime, and add a pre-commit or CI secret-scanning gate so a leaked credential is caught before merge, not after release.
Management guidance
Ask whether secret scanning runs in CI on every pull request, not just as a periodic manual audit — the gap between introduction and detection is where the real risk lives.