When Anthropic's production web application was found exposing JavaScript source maps publicly, it highlighted a class of vulnerability that is simultaneously trivial to introduce and underappreciated in its consequence. Source map exposure is not a theoretical risk — it is a reconnaissance windfall that attackers use to dramatically accelerate their attack timeline against web applications. The Anthropic incident is a useful case study not because the company is uniquely negligent, but because it illustrates how easily frontend security debt accumulates even in engineering-mature organisations.
TL;DR: JavaScript source maps map minified production code back to original source, exposing internal API endpoints, variable names, authentication logic, and file structure. When served publicly, they give attackers the equivalent of reading your codebase. Prevention requires build pipeline discipline and server-level access controls — neither of which is particularly complex, but both require intentional implementation.
What Source Maps Are and Why They Exist
Modern web applications bundle and minify their JavaScript before shipping it to browsers. A React or Vue application that starts as thousands of lines of readable source code gets transformed into a single minified file where variable names are replaced with single characters, whitespace is stripped, and the code is generally unreadable without significant effort. This is desirable for performance and, to a limited extent, for obfuscation.
Source maps exist to solve a developer productivity problem: when a production error occurs, the stack trace points into the minified bundle, which makes debugging nearly impossible. A source map file (typically named bundle.js.map or similar) contains the complete mapping from minified positions back to the original source code, including the original file paths, variable names, function names, and comments. Developer tools in browsers use these to show readable stack traces and allow stepping through original source code during debugging.
The problem is that these files are extremely information-dense. A single source map file for a large application can effectively reconstruct the entire original codebase, including code paths that are never reachable from the user interface.
What Attackers Gain From Exposed Source Maps
During the initial access and reconnaissance phase of an engagement, skilled attackers do not immediately attempt exploitation. They invest time understanding the application's attack surface. Exposed source maps dramatically compress this phase. Here is what becomes visible:
- Internal API endpoint paths: Fetch calls and API client code reveal internal endpoints that are not linked from the UI, including administrative endpoints, internal tooling APIs, and endpoints that handle privileged operations.
- Authentication and authorisation logic: Client-side token handling, role checking, feature flag evaluation, and conditional rendering logic all become readable. Attackers learn exactly what the application expects to authorise specific actions.
- Environment-specific identifiers: Hardcoded strings, internal service names, configuration keys, and comments referencing internal systems or architectural decisions.
- Hidden parameters and undocumented fields: Form fields that are conditionally rendered, query parameters that trigger special behaviour, and request body fields that the UI never populates but the API may accept.
- Third-party integration details: SDK initialisation code often contains identifiers, configuration, and in some cases secrets that were not meant for public consumption.
For an attacker conducting a web application assessment, this intelligence would normally take hours to extract through careful proxy analysis, forced browsing, and API fuzzing. Exposed source maps deliver it in seconds.
Key insight: Source map exposure does not directly compromise a system — it is a force multiplier for every subsequent attack. In a penetration test context, finding exposed source maps significantly increases the likelihood that subsequent findings will be high severity, because the attacker's understanding of the application is now substantially deeper.
How Source Maps End Up in Production
Source map exposure is almost never a deliberate decision. It is the product of build pipeline misconfiguration, usually in one of three ways:
Build Tool Default Behaviour
Webpack, Vite, esbuild, and other modern bundlers have different defaults for source map generation. Some generate source maps in all modes unless explicitly disabled. Developers who configure a build for local development and then promote that configuration upward without reviewing it for production suitability will expose whatever the development configuration emits.
Incorrect Server Configuration
Even when source maps are generated with appropriate access controls in mind, web server configuration can undermine them. If a CDN or origin server is configured to serve everything in a static assets directory without restrictions, source map files get served alongside JavaScript bundles. This is particularly common in S3-backed static hosting where bucket policies are set broadly.
CI/CD Pipeline Mistakes
In more complex build pipelines, source maps may be generated as build artefacts for upload to error monitoring platforms (Sentry, Datadog, etc.) and then inadvertently included in the deployment bundle that goes to production. The intent is correct — use source maps for internal error monitoring — but the implementation does not correctly separate artefacts.
| Root Cause | Common Scenario | Prevention |
|---|---|---|
| Build tool defaults | Dev config promoted to prod without review | Explicit devtool: false in production webpack config |
| CDN/server misconfiguration | S3 bucket serving all static assets publicly | Nginx/Apache deny rules for *.map extensions |
| CI/CD artefact mixing | Sentry upload step includes maps in deploy bundle | Separate upload artefact from deploy artefact in pipeline |
| Missing deployment review | No automated check for map files in release | Add automated source map detection to release pipeline |
How to Audit Your Application for Source Map Exposure
Checking for source map exposure in your own application is straightforward. Load your production application in a browser, open developer tools, and navigate to the Sources or Debugger panel. If source maps are present and accessible, the panel will display the original file structure of your application rather than minified bundles. This is the most immediate signal.
For a more systematic check, inspect the network requests made when loading your application. Look for responses to .js files that contain a sourceMappingURL comment at the bottom of the file. This comment tells the browser where to find the source map. If the URL it references is a relative path or an absolute path on your domain, request that file directly. If you receive a 200 response with a JSON payload, your source maps are publicly accessible.
Automated tooling can assist here. Nuclei has templates for source map detection. During a web application penetration test, this is typically identified in the reconnaissance phase before any active testing begins. If you want to know what an attacker sees when they look at your application, a structured assessment will surface this alongside deeper vulnerabilities.
Preventive Measures: Build Pipeline and Server Controls
Remediation operates at two layers: the build pipeline (controlling whether source maps are generated and where they go) and the web server (controlling whether they are accessible even if they exist).
Build Pipeline Controls
In webpack, set devtool: false for production builds to disable source map generation entirely. If you need source maps for error monitoring, use devtool: 'hidden-source-map', which generates the map file but omits the sourceMappingURL comment from the bundle — the maps exist but browsers will not find them automatically. You then upload the map files directly to your error monitoring platform and exclude them from your deployment artefact.
For Vite, the equivalent is build.sourcemap: false or build.sourcemap: 'hidden'. In Next.js, productionBrowserSourceMaps: false in next.config.js (it defaults to false but is worth making explicit). Confirm your CI/CD pipeline's production build step uses the correct environment flags and that source map files are not included in the deployment package that reaches your CDN or origin servers.
Server-Level Controls
Regardless of build configuration, add a deny rule for .map files at the server level as a defence-in-depth measure. In nginx, this is a simple location block returning 404 or 403 for *.map requests. In Apache, an .htaccess rule with FilesMatch achieves the same. For S3-backed static hosting, a bucket policy or CloudFront function can block access to map file extensions before they reach users.
At Lorikeet Security, source map exposure is part of the standard reconnaissance checklist during every web application security assessment. It is a low-complexity finding to identify but, in combination with other vulnerabilities, it frequently contributes to escalated attack paths. The Anthropic incident is a reminder that frontend security is not a secondary concern — it is part of the attack surface, and it deserves the same deliberate configuration review as any other layer.
Is Your Web Application Exposing More Than You Think?
Lorikeet Security's web application penetration testing engagements cover the full attack surface — from source map exposure and information disclosure to authentication bypass and business logic flaws. Get a clear picture of your risk before attackers do.
