Title: The Importance of JavaScript Obfuscation: Safeguarding Your Code Integrity
JavaScript, being the backbone of modern web development, plays ...
For further actions, you may consider blocking this person and/or reporting abuse
There is exactly one reason to obfuscate your code: minification to reduce bundle size. There is no security benefit to obfuscation. If the interpreter is able to understand the code, so can any experienced developer.
Obfuscation increases the difficulty of just copy-pasting code into ones own project to the point where anyone skilled enough to do so, is also skilled enough and usually better off simply writing their own code.
Whether this is a reasonable goal is, of course a different question, but that's really more on the moral side of things. Some people will write a three-liner and throw a tantrum if it gets "stolen", others will write entire OS kernels and license them so the whole world can just use them.
This isn't to say I agree with anything in the above post, but I don't think "only bundle size" is the entire truth.
You can just pass the "obfuscated" code into a formatter and get the original code. Variable names may be hard to read, but you are mostly fine.
You can NEVER hide client-side code, as it is on the clients end.
That might work for minified code, but properly obfuscated code won't be that easy to make sense of. You really need to spend a lot of time de-obfuscating code.
Keep in mind that many who obfuscate code are willing to trade a bit of performance to make code harder to figure out. There's even obfuscators out there that compile code and bundle it with a VM and other weird stuff like that.
I know about things like JSFuck from aemkei and even created a few similar tricks (hiding code in strings using invisible UTF-8 modifier characters) myself for fun.
But at the end of the day, there is one point in your obfuscated code where you have to evaluate the code that actually runs. One can easily set a breakpoint there and take the unpacked code that the js engine is supposed to be evaluating.
The same is true for web assembly. You can decompile it back to .wat and read what it does that way. That's as much security as an unlocked door.
Having code that is not even worth being copied and pasted is certainly even better security than obfuscation - but especially in that case, obfuscation would be useless.
Obscurity is no security.
But on topic, it makes it harder for the inexperienced maybe.
Obfuscation does nothing for security. If you are the target of an APT or advanced, then obfuscated JS will do exactly nothing.
And if you depend on code obfuscation for security, then your architecture is lacking in good security practices in general. The client should always be considered to be untrusted (if not hostile). Obscurity is not a stand-in for security.
And it does little for copyright. Plus, why reverse engineer and copy-paste when people have Copilot, ChatGPT, etc at their disposal. If it's out there, it's been hoovered and used for training. So it will be miles easier to generate something or find someone on fiver, over trying to reverse engineer something relatively easy.
That pretty much leaves one thing... Decreasing bundle sizes.
And when you're dealing with poor/mobile infrastructure, that's actually a more noble goal.
Please remember that dev.to has guidelines for AI generated content ;)
Good catch!
Is this article AI generated?
It's really hard to tell for sure, it's just giving me heavy AI vibes.
Repeating the title in the body of the article is something chat-gpt did when I had it generate my satire post about broken JS one-liners, so that's an immediate red flag.
But it's also just the plain, family-friendly corporate-speak of the text; it's not impossible that a human would write like that, but it just feels soulless somehow. Like it's just the average of all writing styles, I guess.
Yes. Sus. Flowery beyond context; boiler-plate response. Conspicuous repetition-- No action.
You can link the guideline here for others.
Client side obfuscation is generally a waste of time. Basically, if security is an issue, any business or security related logic should never appear in client side code - obfuscated or otherwise.
In addition to what already others have said regarding that it would only be beneficial for bundle size, your valuable business logic shouldn't even be in the frontend to begin with, and thus you shouldn't be required to hide or protect the frontend logic.
If you have a valuable or critical business logic that you feel obliged to protect in the frontend, then you failed to plan your system properly.
@jonrandy why your comment is hidden?
Dunno, but if you want to see all hidden comments on dev just use the following CSS (on a browser extension like Stylus) (CLICK)
You can also click the date and view the comment's page
And that kind of drives home the point... lol
Who needs an extension?
You could do it with pure JS.
I was pointing out that obfuscation doesn't do a lot if you know how to navigate the issues at hand.
Those who know what they're doing can reverse engineer a site just by using it and logging network requests. No need to even look at the js.
Obfuscation is important if you don't want the client to figure out what your code is doing on their machine. Super shady 👀