The Debugging File Nobody Removed Before Shipping: Secrets Exposed Through a Public Source Map

Modern frontend build tooling produces a specific kind of file that exists purely to help developers debug production code without reading minified, unreadable JavaScript directly — a source map, mapping every compressed, mangled line in the shipped bundle back to its original, readable source. These files are enormously useful during development and, left accessible in production by mistake, hand anyone who finds them a nearly complete, readable copy of the application's actual frontend source code, comments and all.

The target, which I'll call Glasswing Analytics here per their program's disclosure terms, is a business-intelligence dashboard platform with a modern single-page application frontend.

Finding the Map

Checking for exposed source maps is close to the cheapest test in web application testing: request the bundled JavaScript file's own path with a .map extension appended, and see if anything comes back.

GET /static/js/main.a8f3e9.js.map

GET /static/js/main.a8f3e9.js.map

This returned a complete source map file — several megabytes of JSON describing exactly how to reconstruct the original, pre-build source files from the minified bundle actually served to browsers. Feeding this into any standard source-map-aware reconstruction tool produced a near-perfect, readable copy of Glasswing's entire frontend codebase: original file names, original variable and function names, inline code comments, all of it.

Why This Matters Considerably More Than "Now I Can Read Minified Code"

Reconstructed source code from a frontend bundle is interesting on its own for understanding application logic, but the specific, high-value thing worth searching for first is hardcoded configuration — API keys, internal endpoint URLs, and authentication details that a developer embedded directly into frontend code at some point, whether out of necessity, convenience, or a misunderstanding of what "frontend" versus "backend" actually means in terms of who can see the resulting code.

Searching the reconstructed source for common patterns — string literals resembling API keys, references to third-party service SDKs initialized with embedded credentials, internal hostname patterns — surfaced a hardcoded API key for a third-party analytics and error-monitoring service, embedded directly in a configuration file that had clearly never been intended to ship as part of the public bundle at all, based on its file path and the surrounding code referencing clearly internal, staging-environment-specific values alongside it.

Confirming the Key Was Live and Had Real Capability

A hardcoded key found in source isn't automatically a severe finding — plenty of frontend-embedded keys are intentionally scoped to be safe for public exposure, such as a key restricted purely to submitting anonymous analytics events with no read access to anything. The real severity question was what this specific key could actually do.

I tested the key directly against the third-party service's own API, using only read-only, clearly non-destructive calls:

GET https://api.monitoring-service.com/v1/projects
Authorization: Bearer <recovered-key>

GET https://api.monitoring-service.com/v1/projects
Authorization: Bearer <recovered-key>

This succeeded, returning a list of monitoring projects associated with Glasswing's account on that service — including project names referencing what appeared to be internal staging and pre-production environments, environments whose existence and naming wasn't otherwise publicly documented or discoverable anywhere in Glasswing's public-facing product. The key wasn't scoped narrowly for safe public exposure at all; it carried genuine account-level read access to Glasswing's own monitoring configuration.

Mapping What Else the Reconstructed Source Revealed

Beyond the single hardcoded key, reading through the reconstructed source more broadly surfaced several internal API endpoint paths never referenced anywhere in the application's actual, observable network traffic during normal use — endpoints seemingly built for internal administrative tooling that shared the same frontend codebase but were never wired into any UI a normal user would ever reach. I didn't attempt to access any of these endpoints directly, since doing so would mean testing authorization on functionality I had no legitimate reason to probe without further, separate justification — I flagged their existence and the fact that they were discoverable purely through the exposed source map, as a secondary finding worth Glasswing's own internal review.

Scope

I limited active testing to read-only calls against the single recovered monitoring API key, specifically confirming its validity and general capability level without retrieving or reviewing any actual monitoring data, logs, or error reports the key might have granted deeper access to.

The Report

Title: Publicly accessible source map exposes complete frontend source code including a live, overprivileged third-party API key

Root cause: The production build pipeline generates and deploys source map files alongside the minified JavaScript bundle, without restricting their public accessibility. These files allow full reconstruction of the original source code, which includes a hardcoded API key for a third-party monitoring service with account-level, non-public-safe permissions rather than a properly scoped, public-safe key.

Reproduction: The exposed source map file, the reconstruction process yielding readable source, the discovered hardcoded key, and confirmation of its live validity and capability level via a single read-only API call.

Impact: Anyone can reconstruct Glasswing's complete frontend source code and recover a live API key granting account-level access to the company's third-party monitoring configuration, including details about internal, non-public environments never otherwise discoverable.

Fix recommendations:

• Exclude source map files from production deployments entirely, or restrict their accessibility to authenticated internal developers only, which eliminates this entire exposure path regardless of what the underlying source code contains
• Revoke and rotate the exposed API key immediately, and replace any frontend-embedded third-party integration with a properly scoped, public-safe key restricted to only the specific actions the frontend genuinely needs to perform
• Audit the reconstructed source code for any other hardcoded secrets or internal endpoint references, treating this discovery as a signal to review the broader practice of what gets embedded directly into frontend code

What Happened After

Glasswing removed source maps from production deployment and rotated the exposed key within the same week, treating the discovery as a prompt to review their broader secrets-management practices across the frontend codebase rather than treating it as an isolated, one-off oversight.

Why Checking for Exposed Source Maps Belongs in Every Initial Recon Pass

This is among the fastest, lowest-effort tests available against any modern web application, and it's worth running automatically and early against every target, before investing time in deeper, more active testing — because a positive result doesn't just reveal application logic, it frequently reveals exactly the kind of hardcoded secret that turns a quiet recon step into the most severe finding of the entire engagement.