Cleartext Storage / Secrets Leakage

Reports center on secrets stored or accessible in cleartext: API keys in JS bundles, GitHub commits, source-mapped sources, public config endpoints (/config), license-key text files served from CDN, Elasticsearch indices storing Authorization headers, Kubernetes Secrets created from stringData, mobile app binaries containing API keys, and disclosed-and-not-revoked keys in old reports. The detection-actionable subset overlaps heavily with sensitive_files + sourcemap_secret_harvest from Information Disclosure synthesis.

• JS bundles, sourcemaps
• Mobile app binaries
• Public GitHub repositories
• /config and /env endpoints
• License/key download URLs

• Search public Git for company-name + API key regex
• Fetch JS bundles + sourcemaps + grep for secrets
• Probe /config /env /actuator/env
• Decompile mobile app and grep for keys
• Review old disclosed reports for unrevoked secrets

• Regex: AKIA[0-9A-Z]{16} (AWS Access Key)
• Regex: AIza[0-9A-Za-z-_]{35} (Google API key)
• Regex: sk_live_[0-9a-zA-Z]{24} (Stripe)
• Regex: eyJ[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+ (JWT)
• Regex: github_pat_[A-Za-z0-9_]+ (GitHub PAT)
• Regex: xox[abp]-[A-Za-z0-9-]+ (Slack)

Scanning JS bundles and source maps for secret-shaped strings, and probing common config paths like /config and /env with content validation to cut down on false positives, covers most of what's reachable from outside the application. Mobile app binaries require a separate decompilation step and generally fall outside what a web-focused scan can reach directly.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• Many regex matches are example/test keys.
• Validate by checking key prefix + length and never display the full key in findings (truncate to first 8 chars).

Manual Testing Methodology

Here is a systematic approach to identifying Cleartext Storage / Secrets Leakage vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Cleartext Storage / Secrets Leakage specifically, capture traffic on any link expected to be encrypted (including internal/service-to-service where reachable) to check for cleartext transmission, and probe signature or token-verification endpoints with a stripped, empty, or mismatched signature to see whether verification is actually enforced.

Compare the response against your baseline, looking specifically for sensitive data (credentials, personal information, session tokens) visible in plaintext on the wire or in storage, or a request with an invalid/missing signature that the server accepts as valid anyway.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Cleartext Storage / Secrets Leakage, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Sensitive data stored or transmitted in cleartext is exposed to anyone with read access to the storage layer or the network path — a database backup, a misconfigured bucket, or a passive network observer on an unencrypted link all yield the data directly, with no cryptographic barrier to defeat first.

Broken cryptographic-signature verification is a related but distinct failure: even where encryption is used correctly elsewhere, a signature check implemented as a naive string comparison (rather than a constant-time comparison) or that accepts a malformed or absent signature can let an attacker forge tokens, licenses, or authenticated messages outright.

Both failure modes tend to surface only when it's already too late — in a breach post-mortem, a compliance audit, or a researcher's report — since neither one changes the application's normal behavior in a way that would be caught by functional testing alone.

Prevention and Secure Coding

Preventing Cleartext Storage / Secrets Leakage takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Encrypt sensitive data at rest. Apply encryption to sensitive fields and backups at the storage layer, with key management separated from the data itself.

TLS everywhere, including internal traffic. Enforce TLS for all data in transit — between the client and the edge, and between internal services, since an internal network is not an implicit trust boundary.

Constant-time signature comparison. Verify cryptographic signatures using the crypto library's constant-time comparison function, never a plain ==/.equals() check, which leaks timing information an attacker can use to forge a valid signature byte by byte.

Keep TLS configuration current. Disable legacy protocol versions and weak cipher suites, and monitor certificate expiry actively rather than reactively.

Minimize what needs protecting. Don't retain or transmit sensitive data that isn't actually needed — the cheapest way to reduce cleartext-exposure risk is to reduce the surface that requires protection at all.