Decide what customers should receive
Start with a distribution decision. An open-source library may intentionally publish source and maps. A proprietary web application may keep complete maps in restricted diagnostic storage. These are different release policies, and a scanner should not silently choose between them.
Document the assets that are meant to be public, the team that can retrieve diagnostic files, and the minimum retention needed to investigate supported releases. Removing every old map may reduce exposure while making an urgent production incident much harder to diagnose.
Separate the two outputs
Build once and retain a release identifier that links the public bundle to its private maps. Upload diagnostic files to the chosen restricted system before deleting them from a public staging directory. Keep that private destination outside the hosting root and deployment archive.
A hidden-map option commonly suppresses the sourceMappingURL comment; it does not itself deny HTTP access to the map file. A guessed app.js.map URL can still expose a file if the hosting configuration serves it. Review inline maps too, because they travel inside JavaScript.
Validate the release path
Audit the exact public tree, not the source checkout. For a supported loose web release, CloneGuard can stage another tree that excludes known private artifacts and preserves retained bytes. Fix inline maps in the bundler and rebuild, because staging does not rewrite them.
python3 /tools/cloneguard/cloneguard audit ./dist --scope release
python3 /tools/cloneguard/cloneguard stage ./dist --out ../public-release --dry-runClose the deployment gap
After deploying to an authorized environment, request representative map URLs and inspect both status and body. An SPA fallback returning HTML with status 200 is not a source map, but it is also not proof that every other asset path is private. Include old hashed chunks and any separate asset hostname.
Finally, provoke a harmless test error in a nonproduction environment and confirm that the diagnostic system resolves it using the matching private map. The useful outcome is a smaller public release with working incident response, not an unsupported promise that the remaining code cannot be understood.
Check a rollback as well as a new release
Consider a site that keeps three hashed releases available so clients with old HTML can still load their chunks. Removing maps only from the newest upload leaves two older map sets reachable. Record all supported release prefixes in the deployment check and apply the same public/private policy to each. If you intentionally retain public historical artifacts, document that exposure instead of reporting them as removed. A rollback exercise should confirm that the older public bundle still loads and that its matching private map remains retrievable by the incident team. This catches both incomplete cleanup and diagnostic retention mistakes.
Practical checklist
- Name the policy owner and allowed readers.
- Keep public bundles and private maps linked by release.
- Check inline maps, CDN paths and historical assets.
- Confirm a representative stack trace can still be resolved.
Sources and further reading
Primary references support the technical details. Procedures here are guidance; only explicitly recorded project results describe tests we ran.
Prepared with AI assistance. How this library is produced. Suggest a correction; keep private code and credentials out of public issues.