Your team enabled full source maps on the production bundle so on-call can debug live errors, and a security reviewer flagged it. How do you weigh the observability benefit against the security concern, and what would you actually ship?

technical-conceptual · Senior level · software-engineering

What the interviewer is really asking

Assesses whether the candidate can navigate a real build-configuration trade-off between debuggability and exposure, landing on a concrete configuration rather than an absolute yes/no.

What to say

• State the genuine value: source maps map minified stack traces back to readable code, so production errors in your monitoring tool are actionable instead of pointing at column 4 of a minified line.
• State the exposure: publicly served maps hand anyone your original source, folder structure, comments, internal API shapes, and feature flags, which has caused real incidents when .map files leaked.
• Propose the practical middle ground: generate hidden source maps (no inline comment in the bundle) and upload them privately to the error-monitoring service or restrict them behind auth, so on-call gets readable traces while the public never downloads the maps, and consider stripping embedded source content.

What to avoid

• Treating it as binary: either ship full public maps or have no maps and lose all production debuggability.
• Assuming 'hidden' source maps are safe to deploy to a public directory, when attackers can still guess and fetch the .map filename unless access is blocked.
• Dismissing the security concern as paranoia, or conversely dismissing the on-call need without offering an alternative.

Example answers

Strong: Both sides are right, so I wouldn't pick one. Source maps make our error tool show real stack traces, which on-call genuinely needs. But serving them publicly exposes our whole source, and that's bitten companies when a stray .map file leaked. I'd generate hidden source maps so there's no comment pointing the browser at them, upload them privately to our monitoring provider, and make sure the build never deploys .map files to the public bucket so they can't be guessed and fetched.

Weak: Source maps are needed for debugging in production, so we should just keep them on. If security is worried we can revisit later, but on-call comes first and a leaked map isn't that big a deal.