Hook
Production errors are much easier to fix when stack traces point to readable files and lines. But if a source map sits next to your JavaScript and anyone can download it, debugging turns into a public tour of your source code.
On May 14, 2026, Vercel launched Protected Source Maps and made the option enabled by default for new projects. For existing projects, this is a good moment to do a short audit: should every visitor really be able to fetch your .map files?
Problem / Context
In production, frontend code usually goes through a build step: files are bundled, compressed, names are shortened, and the result becomes faster for the browser. That is good for users, but uncomfortable for debugging. When an error comes from a file like app-8f3a91.js, nobody wants to manually guess which component failed.
A source map solves that. It tells tools that this part of the minified code corresponds to a specific original file and line. DevTools or an error tracker can then show a useful stack trace instead of a tiny unreadable bundle.
The side effect is obvious: a source map can expose project structure, file names, parts of application logic, comments, or other details the team did not intend to publish. This is not always a disaster, but it is absolutely a risk surface. It matters even more when code includes internal routes, feature flags, careless comments, or logic that is convenient for competitors and attackers to study.
Next.js warns about this directly: browser source maps are disabled in production by default to prevent client-side source leaks. If a team enables productionBrowserSourceMaps: true, the files are emitted next to JavaScript and Next.js can automatically serve them when requested. On Vercel, Protected Source Maps adds access control at that exact point.
Why it matters
Teams often end up between two extremes. One extreme is disabling source maps completely and then debugging production issues almost blind. The other is enabling them in production and never checking who can download .map files. Both choices have a cost.
Protected Source Maps offers a middle path. The team keeps readable stack traces and browser debugging, while Vercel checks access to .map files through Vercel Authentication. Authorized team members can fetch source maps. Everyone else gets 404 Not Found, not confirmation that the file exists but is forbidden.
Important caveat: this does not make bad frontend security safe. Anything that truly runs in the browser is still shipped as JavaScript. Source map protection does not replace a real security model. It removes an unnecessary helper file that makes reverse engineering much easier.
Illustration: what is actually protected
Think of a production deployment as a storefront. Minified JavaScript is the product on the shelf: the browser must receive it, or the site will not work. A source map is the internal warehouse diagram that shows how everything is organized. The diagram is useful for the team. It is unnecessary for a random visitor.
Protected Source Maps locks the browser .map files, not the site itself. If a person has access to the deployment, they can debug. If not, a source map request looks like the file is not there.
How to do it
1. Check whether the production build generates source maps
Start with configuration. For Next.js, the key flag looks like this:
// next.config.js
module.exports = {
productionBrowserSourceMaps: true,
};
If that flag is absent, it does not automatically mean source maps are absent. The project may use another build tool, a separate Webpack configuration, a Sentry plugin, or a custom pipeline. But it is a fast first check.
After the production build, inspect the output. If files like *.map appear next to JavaScript or CSS, the question is no longer theoretical.
2. Test access from the outside
Open the production or preview URL in a private browser window without a Vercel login. In DevTools, find a JavaScript asset and try to open the source map URL from sourceMappingURL, or add .map where appropriate.
For a manual terminal check, a simple request is enough:
curl -I "https://your-app.example/_next/static/chunks/app/example.js.map"
If the unauthenticated request returns 200, the source map is public. If it returns 404 after protection is enabled, Vercel is hiding the file from outsiders.
3. Enable Protected Source Maps in Vercel
For existing projects, open the Vercel Dashboard, go to project settings, then Deployment Protection, and enable Protected Source Maps. According to Vercel’s docs, the change applies on the next .map request and does not require a redeploy.
If your platform team manages settings through an API, the relevant project field is protectedSourcemaps: true. That is useful for larger teams, but for most small teams the dashboard path is faster and less error-prone.
4. Verify browser debugging
After protection is enabled, DevTools may not simply load .map files on its own, because browser requests for source maps do not automatically include your Vercel session. Vercel’s intended path is the Vercel Toolbar: open the deployment, activate the Toolbar, sign in with an account that has access, enable Debug Mode, and reload the page.
Do not stop at “the toggle is on.” Use a real production error or a test throw in preview, open the stack trace, and confirm it resolves to readable files instead of only the minified bundle.
5. Check automation and error tracking
Not every tool behaves like a human in a browser. CI/CD, Playwright, monitoring, or an error tracker may access protected deployments automatically. For those cases, Vercel provides automation bypass: a secret passed through a header or query parameter.
The better practice is to keep the secret in an environment variable, not in code or public URLs. After enabling source-map protection, check:
- whether E2E tests still pass against protected deployments;
- whether monitoring is not receiving unexpected 404 responses;
- whether the error tracker still maps stack traces correctly;
- whether the bypass secret is absent from logs and repositories.
6. Remember the feature boundaries
Protected Source Maps applies to browser source map files served from a deployment. It does not change inline source maps, server-side source maps used by Vercel Functions, or source maps separately uploaded to a third-party service.
If you have a separate upload to Sentry or another error tracker, audit that path separately: who can access the artifacts, whether the storage bucket is public, and whether source maps accidentally landed in a static public directory.
Anti-patterns
- enabling
productionBrowserSourceMaps: trueand never checking URLs manually; - assuming source maps are safe because “nobody knows the link”;
- disabling source maps entirely and leaving the team without usable production debugging;
- giving every tool the same automation bypass secret without a need;
- storing a bypass token in the repository or logs;
- assuming Protected Source Maps hides all frontend code;
- setting
protectedSourcemapsback to false without realizing .map files become public again on the next request.
Conclusion / Action plan
Protected Source Maps is a small option with a very practical effect. It is not a magic safe for frontend code, but it removes unnecessary public access to files that make your code much more readable.
What to do next:
- find whether the production build creates
*.map; - test several .map URLs without authentication;
- enable Protected Source Maps for the Vercel project;
- verify DevTools through Vercel Toolbar and Debug Mode;
- check CI/CD, monitoring, and error tracking;
- record the decision in the release checklist.
Official sources:
- https://vercel.com/changelog/protected-source-maps-ship-browser-source-maps-securely
- https://vercel.com/docs/deployment-protection/protected-source-maps
- https://vercel.com/docs/deployment-protection/methods-to-bypass-deployment-protection/protection-bypass-automation
- https://nextjs.org/docs/pages/api-reference/config/next-config-js/productionBrowserSourceMaps
Quick checklist
- Check whether the production build generates browser source maps.
- Try opening several .map URLs without authentication.
- Enable or verify Protected Source Maps in Vercel Deployment Protection.
- Verify debugging through Vercel Toolbar and Debug Mode.
- Check CI, Playwright, monitoring, and error tracking after the access change.
- Document who may view source maps and how automation bypass is handled.
Prompt Pack: audit production source maps
Help audit whether production source maps in our frontend project are publicly exposed. Input data: - deployment platform: Vercel, another cloud, or self-hosted; - framework and build tool: Next.js, Vite, Astro, Webpack, or another stack; - relevant next.config.js or build configuration; - several production asset URLs from DevTools or HTML; - whether the team uses an error tracker; - whether CI/CD, Playwright, monitoring, or other automation needs access to protected deployments. Return: 1. whether the build generates browser source maps in production; 2. which URLs should be checked manually; 3. whether .map files are publicly accessible; 4. what Vercel Protected Source Maps will change; 5. how to verify DevTools, Vercel Toolbar, error tracker, and automation bypass; 6. a rollback plan in case debugging or tooling breaks. Response format: short conclusion, risks, verification steps, recommended changes, post-enable checklist.