Hardcoded Azure App Configuration credentials in public JavaScript (candidate, unconfirmed impact)

Target redacted. This finding is not submitted to the program nor publicly disclosed yet, so hostnames are replaced with redacted.example and account identifiers are removed. The technical detail is kept intact.

Summary

A public JavaScript bundle shipped four Azure App Configuration connection strings — including the production store — reachable by anyone loading the site, and the same strings appeared in an in-scope Android APK.

Why it is still a candidate

The impact is only provable by one authorised read against the store (*.azconfig.io/kv/) signed with the HMAC secret from the bundle. That single request was never approved, so this stays a documented candidate: the credentials are objectively exposed, the blast radius is not yet demonstrated.

Impact if confirmed

• Read of production configuration: feature flags, endpoints, possibly third-party keys.
• Write access is plausible with the same credential, which would allow config poisoning of the

production deployment.

Evidence

• Bundle and APK both contain Endpoint=, Id=, Secret= triples for the same store.
• Secret present client-side, no runtime fetch, no rotation indicator.
• Estimated CVSS around 9.3 (network, no privileges, high confidentiality/integrity), pending proof.

Remediation

Treat the store credential as compromised: rotate, move all reads behind a backend, and use managed identities with scoped read-only roles. Client bundles are public by definition.

Lesson

Grep bundles and APKs for cloud SDK connection-string shapes, not just API keys. A secret in a public bundle is a finding even when you are not allowed to prove the blast radius — say so explicitly instead of inventing severity.