Docs / Checks / Security

Updated July 31, 2026 · Security · Medium severity

Source maps and version headers exposed publicly

Seen in 15 of 450 scanned projects (3%). Based on 450 Deep Scan runs across production projects.

Common stacks: Next.js Nginx Sentry CDN

How to tell you have it

Why it matters

A source map is essentially the original source code with a decoder ring attached. When it is reachable by anyone, so is your logic, your internal comments, your API route structure, and sometimes literal strings like internal endpoint names or feature flags that were never meant to be public. This is true even for pages sitting behind a login screen in the app, since the map file itself is a static asset served with no auth check of its own.

Version and framework fingerprinting headers turn a blind attacker into an informed one. Once someone knows you run a specific framework version, they go straight to that version's known CVE list instead of guessing, which meaningfully cuts down the time and effort needed to find a working exploit against you.

PHP and Apache version disclosure is an old problem that still shows up constantly in default configs. Combined with a public source map or a verbose error page, it gives an attacker a very precise picture of your stack with almost no effort on their part.

Missing Subresource Integrity on third-party CDN scripts means you are trusting that CDN completely, forever, with no way to detect if it starts serving something different. If that CDN is ever compromised or misconfigured, the altered script runs on your site with full page access and your visitors have no way to know.

How Heygents detects it

How to fix it

1. Check whether source maps are publicly reachable Find a built JS bundle path from the rendered HTML, then request the matching .map file directly.
2. Disable map emission in the production build Most frameworks let you turn off client source map generation for production builds while keeping them for staging or local debugging.
3. If you need stack traces, upload maps directly to your error tracker instead Generate maps at build time but never ship them to the public CDN path. Upload them privately to Sentry or an equivalent so error reporting still gets readable stack traces without exposing source to visitors.
4. Strip fingerprinting headers at the reverse proxy Remove X-Powered-By and rewrite the Server header at the edge so version details never leave the server, regardless of what the app framework sets by default.
5. Add Subresource Integrity to third-party script tags Generate the hash for each pinned CDN script version and add it to the tag so the browser refuses to execute a script that does not match.

Check whether source maps are publicly reachable

curl -s https://example.com | grep -oE '/_next/static/[^"]+\.js' | head -1
curl -s -o /dev/null -w '%{http_code}\n' https://example.com/_next/static/chunks/main.abc123.js.map

Disable map emission in the production build

{
  "productionBrowserSourceMaps": false
}

If you need stack traces, upload maps directly to your error tracker instead

sentry-cli sourcemaps upload --release=$RELEASE ./dist

Strip fingerprinting headers at the reverse proxy

server_tokens off;
more_clear_headers 'X-Powered-By';
proxy_hide_header Server;

Add Subresource Integrity to third-party script tags

<script src="https://cdn.example.com/lib.js" integrity="sha384-<hash>" crossorigin="anonymous"></script>

Frequently asked questions

Do source maps behind a login page still count as exposed?

Yes. The map file is a static asset with its own URL, and static asset servers typically do not check the same auth session as the app page that references them. Anyone who guesses or scrapes the map path gets the source regardless of whether the referring page required login.

Is X-Powered-By really worth removing, since the framework is often obvious anyway?

It is worth removing because it turns a guess into a certainty and often includes the exact minor version, not just the framework name. Small friction adds up, and removing it is a one-line config change with no downside. Strip it at the reverse proxy rather than in app code, since error pages and static asset responses frequently bypass application middleware entirely.

Will disabling source maps break my error tracking?

Only if you rely on the public map for stack traces. Upload maps privately during the build step to your error tracking provider instead, which gives you full readable stack traces in your dashboard without publishing the source to anyone who requests the file.

Do I need Subresource Integrity for scripts I host myself?

No. Subresource Integrity matters specifically for third-party origins you do not control, such as a public CDN or an analytics vendor, where the file can change under you without warning. For assets served from your own domain your deploy pipeline is already the trust boundary, and adding integrity hashes there mostly creates cache-busting headaches for no security gain.