Response Content Leakage

This check scans your HTML response body for five distinct kinds of accidental leakage: production source maps that expose your original code, HTML comments referencing internal or staging URLs, large blocks of commented-out code, page references (href/src/action) pointing at internal hosts, and HTTPS pages with form actions on plain HTTP. Most of these come from build pipelines and template hand-edits that are easy to fix once surfaced.

How the check works

Per primary host, the check parses the response body and deducts points for each pattern found, out of a 30-point per-host budget:

• Source maps detected (deduction 15, reason source_maps_exposed): body contains .js.map, .css.map, sourceMappingURL, or sourcemap; or a Sourcemap or X-Sourcemap response header is set. Source maps reveal full original source code, including comments and (sometimes) credentials hardcoded in dev.
• Internal URLs in HTML comments (deduction 8, reason internal_urls_in_comments): comments contain URLs with internal hostnames (.internal, .local, .corp, .lan) or staging./dev. prefixes. IE conditional comments are excluded.
• Commented code blocks (deduction 5, reason commented_code_blocks): three or more HTML comments each longer than 500 characters. Suggests commented-out features or debug code shipped to production.
• Internal references in source attributes (deduction 10, reason internal_refs_in_source): any href, src, action, or data-* attribute containing an RFC 1918 IP or internal hostname pattern.
• Insecure form action on HTTPS page (deduction 7, reason insecure_form_action): page is HTTPS but contains a form with action=http://. Form submission goes over plaintext.

Total deduction is capped at 30. Score = (30 - deduction) / 30. Per-host scores are weighted (apex highest) and averaged. Verdict thresholds: pass at 0.9 and above, warn at 0.45 and above, fail below.

How the verdict maps to evidence

• Pass: no leakage patterns on any primary host.
• Warn: one or two minor signals on at least one host.
• Fail: source maps detected, internal references in attributes, or several signals stacking.

Evidence shows host_rows with each finding's reason code, plus per-host counts (source_maps_detected, comment_hits, large_comment_blocks).

Special states

• Not Applicable: primary host serves a default/empty placeholder page.
• Degraded: probe data unavailable, or no response body was captured. Fix Web Assessability first.

Fix by reason code

source_maps_exposed (deduction 15)

Source maps map your minified production JS/CSS back to the original sources, including comments, original variable names, and (in dev builds) hardcoded secrets. They are essential for debugging, but should not be served from public URLs alongside the minified files. Two paths:

• Stop generating source maps for production builds. webpack: devtool: false (or hidden-source-map for emitting maps without the URL comment). Vite: build.sourcemap: false. esbuild: --sourcemap=external (writes the file but no URL reference). Next.js: productionBrowserSourceMaps: false (default).
• Generate them, upload them only to your APM (Sentry, Datadog, Honeycomb), and exclude them from the public deploy. CI uploads source maps to the APM, then deletes the .map files before publishing the bundle.
• Strip the //# sourceMappingURL= comment from the bottom of bundles even if the .map files are not deployed. Otherwise browsers ask for files that may exist on a CDN or backup.

If you find your source maps publicly served, treat any secrets that ever appeared in source code as compromised: rotate API keys, OAuth client secrets, and any other tokens that lived in JS files.

internal_urls_in_comments (deduction 8)

Build pipelines, CMS exports, and template engines often leave HTML comments behind referencing staging or internal URLs ("<!-- generated by build-server-03.internal -->", "<!-- staging.yourdomain.tld -->"). Strip them in your build:

• Webpack: html-webpack-plugin's minify option (removeComments: true).
• Vite: html-minifier-terser via vite-plugin-html.
• Next.js: production builds strip comments by default; review your custom _document.tsx for stray <!-- --> blocks.
• WordPress / Drupal / static site generators: most have a comment-stripping plugin or option.
• Audit your CI build outputs to confirm no internal hostnames make it to public HTML.

commented_code_blocks (deduction 5)

Large HTML comment blocks usually mean someone commented out a feature, an old layout, or vendor-injected debug content. Use version control instead of commenting out code, and have your build strip comments per the configurations above.

internal_refs_in_source (deduction 10)

Page attributes (href, src, action, data-*) point at internal or staging hosts. The page renders fine externally because the user's browser cannot reach those URLs, but every visitor sees evidence of your internal topology in view-source. Common causes:

• Hardcoded environment URLs in templates that were not parameterized (https://staging.yourdomain.tld instead of {{ .Site.BaseURL }}).
• Image or script tags pointing at internal CDNs (https://internal-cdn.corp/asset.js).
• data-* attributes for analytics or feature flags that include internal endpoint URLs.

Fix by replacing internal hostnames with public-facing equivalents (or with relative URLs where same-origin), and audit your build for environment-specific URL templating.

insecure_form_action (deduction 7)

An HTTPS page with a form action="http://..." submits form data over plaintext, which most browsers now warn about explicitly. Update form actions to https:// or to relative URLs (action="/login") so they inherit the page scheme.

Verify the fix

• curl -sL https://yourdomain.tld | grep -iE 'sourcemappingurl|\.js\.map|\.css\.map|<!--' to spot-check for source maps and HTML comments.
• curl -sL https://yourdomain.tld | grep -oiE 'https?://[^"'\"]+' | sort -u to list every URL in the page; visually scan for internal-looking hostnames or http:// references.
• Browser DevTools → Sources panel: the file tree only shows the bundled files, not original sources, when source maps are absent.
• Re-run the RedScore lookup. Pass requires no leakage patterns on any primary host.

Common pitfalls

• Source maps removed from main bundle but still on a CDN. .js.map files often live alongside .js on the same CDN. Check your CDN bucket directly; deleting from the local build does not delete remote copies.
• Source map comment stripped but maps still reachable. Some bundlers strip the //# sourceMappingURL= line but still upload the .map files. Anyone who guesses the filename can fetch them. Either delete from CDN or rely on hashed filenames + private upload.
• Internal URL stripping breaks dev workflow. If your dev environment depends on those internal URLs, gate the comments and references behind environment-specific build flags so prod builds output only public hostnames.
• Stripping comments breaks legitimate ones. Some browsers respect <!--[if IE]>--> conditional comments (mostly historical) or <!-- prerender --> hints. Configure your minifier's exception list.
• Form action=// (protocol-relative). Modern browsers handle it fine, but some configurations resolve // to http://. Prefer absolute https:// or relative /path.
• data-* attributes leaking via templating. Any data attribute that templates a full URL can leak; audit your template helpers and prefer hostname-less paths.