This week’s React Status newsletter hit my inbox, and as per usual contained a roundup of things that happened in the React ecosystem that you’ll probably want to know about and some interesting articles. One of those articles was Everything You Need to Know About Source Maps.
Source maps are an important thing to know about if you’re a frontend developer. They map the code in your bundled, minfied JavaScript and CSS files to your source code to make it easier to debug in the browser.
I think that Neciu Dan’s article has some good information about what source maps are and techniques for keeping them out of your production build, but I take issue with his statements about source maps and security. Note that when I say “security”, I’m talking about cybersecurity, not keeping your roadmap or closed source IP secure. If making IP theft inconvenient is important, then definitely keep your source maps out of the public’s browsers.
On to the statements I take issue with, starting with these two:
Unless you proactively remove or block
.mapfiles, your actual source code can become accessible to anyone with browser access, potentially revealing sensitive logic or secrets. Overlooking this risk can lead to serious security breaches if not addressed carefully.
Sourcemaps have leaked API keys and secrets that developers inlined into client code, thinking minification hid them. (Hopefully you don’t do this)
Secrets and anything else sensitive should never be in your client-side code. If that’s happening, you need to get those secrets out of your bundle and rotate your keys ASAP, not waste time fiddling with your build toolchain or CI/CD pipelines to make the source maps go away.
Even if you do get rid of the source maps, it’s a trivial exercise to extract API keys from a bundle. Why? Well because they’re strings, so they’re not replaced like identifiers. (How would an API key work if it were replaced with different characters anyway?) Take a look at this bundled code from a phishing site that landed in my inbox. Wasn’t that nice of them to ask if I’d like to talk to a recruiter about working for Marriott!
You can clearly see all the strings are intact. An attacker can simply use a SAST (static application security testing) tool, like Snyk Code, to sniff for secrets in the bundle. (No, I don’t receive any compensation from Snyk).
SAST tools are intended to help developers keep secrets out of git and detect security vulnerabilities in order to fix them, but they can also be used maliciously to find hardcoded secrets and vulnerabilities. In the case of API keys, you don’t even need to get that high tech to extract them from a bundle. Many API keys have patterns and/or prefix characters, and it’s possible to locate strings that look like API keys using nothing more than a Bash script.
Summing it up, secret strings in your bundle aren’t even obscure. But what about using the frontend code to learn about the backend? Neciu thinks that source maps are a security risk there too:
And the people watching for this aren’t curious hobbyists. They’re scraping production bundles of large sites looking for exactly these mistakes, because internal endpoint names and request shapes are the starting map for probing a backend.
Let’s walk through how easy it is to learn about the backend from the client-side code even if there’s no source map.
Starting with finding endpoints, the URLs and paths in your code are also strings. So you have the same issue there as with API keys. I don’t think I need to explain how easy it is to find strings that look like URLs or paths.
But things that aren’t strings are also easy to see without a source map. Enter the unbundler. These are tools for decompiling and unbundling JavaScript. The unbundled code isn’t as easy to read as the original source code, but it’s still pretty clear. Especially if you’re just interested in what data is being sent between the server and client, and the shape of the data.
I’ve been using Wakaru for unbundling, and it’s an awesome package. Obviously, you can use these tools for security research, but they’re also useful when you need to debug your broken bundle.
Here’s a screenshot of that same phishing site’s POST request to their backend, unbundled using Wakaru. Easy to read, right?
In case you were wondering, this phishing site shows you a fake Google login modal that’s not really a separate browser window like the real one is. They dressed up some divs and a form to look like the Google sign-in window. After you put your email address and password into the fake window, the React app submits the form to the phisher’s backend.
Your client-side code is not a place to try to obfuscate what your backend looks like, source maps or no. The only solution to that is more backend. Only let your frontend talk to a proxy server.
Remember that security through obscurity is no security at all. Also remember that your bundler leaves the strings as-is. That’s my PSA for today.
Leave a Reply