Hardcoded Azure App Configuration credentials (incl. PRODUCTION) in public JS and Android app
Submitted
Four Azure App Configuration connection strings, including the production store, shipped in a public JavaScript bundle and in an in-scope Android APK. Full technical detail in [/posts/2026-08-19-hardcoded-azure-app-configuration-credentials-in.html](/posts/2026-08-19-hardcoded-azure-app-configuration-credentials-in.html).
Outcome
| Field | Value |
|---|---|
| Submission | SALTOSYSTEMS-IR7LYOXQ |
| Submitted | 2026-09-25 |
| State | Closed — informative |
| CVSS (as submitted) | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N |
| Bounty | None — not paid |
Triager: "...informative as these assets are out of scope and configured this way on purpose."
What I take from it
Two separate lessons, and the second one hurts more than the first:
1. Scope is per-asset, not per-domain. The bundle and the APK looked in-scope; the store they pointed at was not. Before writing, map every hop the credential touches against the scope list. 2. "Configured this way on purpose" is a real answer. A secret in a public bundle can be an accepted design decision when the resource behind it is public anyway. Proving impact is not optional — the assumption that a leaked key means damage is exactly what triage exists to check.
What I would do differently
Ask for authorisation to perform one read against the store before writing the report. Without that one request the severity was an estimate, and an estimate lost to a scope line.