Your Source Code Is in Production: The Hidden Danger of Turbopack Sourcemaps

Your Source Code Is in Production: The Hidden Danger of Turbopack Sourcemaps
Photo by Adam Birkett / Unsplash
"We deployed our app using Next.js and Turbopack... and accidentally exposed our entire source code."

That’s not clickbait. It’s happening.

If you’re experimenting with or already using Turbopack, the Rust-based successor to Webpack in the Next.js ecosystem, there’s something you need to know right now:

Turbopack currently always generates production sourcemaps for the browser — and they contain your actual source code.

Wait, What’s a Sourcemap?

Sourcemaps are files that map your compiled code (the stuff browsers read) back to your original source code. They’re fantastic for debugging — especially in development.

But here’s the catch: in production, they can become a security risk if not handled properly.


The Real Risk: Source Code Leaks in Production

Here’s what’s really happening:

  • Your app is deployed to production with .map files.
  • These sourcemaps contain your original code, including:
    • Component logic
    • Business rules
    • Even developer comments
  • Anyone who finds those .map files can read your code — right from the browser.

This isn’t just a theoretical problem. We’ve seen:

  • Leaked API keys embedded in client-side logic
  • Internal developer notes exposed in comments
  • Proprietary algorithms being copied

Why This Is Happening in Turbopack

Turbopack is still under active development. At the time of writing:

  • It does not yet expose config options to disable or restrict sourcemap generation in production.
  • That means unless you intervene, your source will ship with your production build.

How to Fix or Mitigate It

While Turbopack doesn’t have a toggle yet, you can still protect yourself.

1. Strip Sourcemaps Before Deployment

After running your build, delete all sourcemap files:

find .next -name '*.map' -delete

Make this part of your CI/CD pipeline. It’s your last line of defense.


2. Block Access at the Server Level

If you’re serving your app through a custom server or reverse proxy (like Nginx), add a rule to deny .map files:

location ~* \.map$ {
    deny all;
}

For Vercel deployments, use vercel.json:

{
  "headers": [
    {
      "source": "/(.*)\\.map",
      "headers": [{ "key": "x-robots-tag", "value": "noindex" }]
    }
  ]
}

3. Audit Your Production Builds

Don't just assume everything is safe.

  • Open your deployed site.
  • Open DevTools → Network tab.
  • Refresh and filter for .map.
  • If you see anything — take it down or block it.

What Else Should You Worry About?

  • Error tracking tools (like Sentry) require sourcemaps. If you’re using them, make sure to upload sourcemaps privately, not serve them publicly.
  • Watch for API key exposure or comments in code. Sourcemaps often include more than you expect.
  • This also applies to private projects. Even internal dashboards can leak.

The Bigger Picture

This isn't a "Turbopack is bad" post — quite the opposite. Turbopack is incredibly fast and promising.

But as developers, we must treat build tooling with respect, especially when it’s new. Assume nothing. Check everything.


Finally

If you’re pushing code to production, always ask:

🔐 “Did I just give away more than I built?”

You might be surprised.

Support Us