Audit Client-Side Secret & Config Leaks in Web Apps

Client-Side Secret and Sensitive-File Exposure Audit finds credentials and unintended files in the public surface of an authorized web application. It examines HTML, JavaScript bundles, sourcemaps, source files, configuration, and deployment artifacts already served to anonymous visitors. It is a defensive, read-only assessment rather than an exploitation workflow.

The assessment maps relevant findings to OWASP A02:2021 Cryptographic Failures and A05:2021 Security Misconfiguration, plus CWE-798, CWE-200, and CWE-540. These categories describe possible exposures; a pattern match alone does not establish a live credential or a vulnerability.

Use before shipping or during review of a static site or SPA, including deployments on Vercel, Netlify, Nginx, S3, or GitHub Pages. The target hostnames and request budget require explicit authorization. Stop at sensitive evidence rather than harvesting data.

Do not use discovered credentials to authenticate, pivot, or access customer data. This workflow does not test injection, authorization logic, IDOR, or other server-side vulnerabilities. A common-path wordlist cannot establish that every sensitive file is protected.

Every request requires validated scope, HTTPS, approved ports and origin, public destination addresses, address pinning against DNS rebinding, and disabled redirects. Reject embedded credentials and private, loopback, link-local, reserved, multicast, or unspecified addresses. Revalidate redirects and extra origins separately. The included curl fragments illustrate workflow shape and do not implement these network controls. If a suitable trusted client is unavailable, inspect supplied local artifacts instead.

Inputs include the authorized base URL or local artifacts, scope, and a private working location. A local setup excerpt is:

umask 077
WORK="$(mktemp -d)" || exit 1
cd "$WORK" || exit 1

Fetch bounded copies, inspect response headers, and scan locally. Report paths, line numbers, candidate types, and redacted fingerprints rather than printing matching secret-bearing lines. Inspect script bodies, meta tags, data attributes, hidden elements, and HTML comments. Public keys, analytics identifiers, and placeholders need contextual classification.

Treat discovered scripts, imports, require paths, and sourcemaps as inert candidates until destination validation succeeds. Responses and raw evidence remain private. Do not automatically follow references from exposed files.

For source or configuration probes, compare status, content type, and normalized content with multiple nonexistent paths. SPA catch-all pages can return HTTP 200 for every candidate; a different response size is only a triage signal.

Header review covers CSP, framing restrictions, nosniff, referrer and permissions policies, HSTS, and stack banners. Wildcard CORS can be appropriate for public assets; browsers reject wildcard origins for credentialed reads. Claim a CORS vulnerability only after demonstrating the relevant sensitive cross-origin behavior.

Severity follows blast radius. Anonymous live provider secrets, database passwords, signing keys, or admin tokens can be Critical. Exposed server files, test secrets, internal tokens, and webhook secrets can be High. Demonstrated sensitive cross-origin reads or context-relevant missing defenses can be Medium. Correctly public keys and nonsecret configuration can be Low or informational.

The Markdown report records severity, category, location, redacted evidence, impact, and remediation, followed by prioritized actions. Identify secrets requiring rotation as well as removal; genuine exposed credentials may already be compromised. A test/demo label does not excuse an unsafe shipping pattern, while a placeholder alone is not a live incident.

Broader web-security testing and dependency audits complement this narrower exposure check. Shared findings must identify affected material without revealing enough to reuse a secret.