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.
Nah, someone out there will de-obvuscate it just for kicks and throw it up on paste-bin.
Or an AI crawler that "writes code".
Yes, you always need to make sure to avoid the Streisand effect. Try too hard to make your code look juicier than it is and you might attract people who don't want the code itself but just seek the challenge.
But most cases where obfuscation is used, the code being "protected" is usually boring enough that nobody really cares. Code that really is so amazing anyone important might want to copy it usually isn't front-end javascript code.
The juice is in what the code does and how well it works. That's what people see.
And so... you are saying that basically all the really cool graphical effects and games and myriad interfaces are not juicy?
Then why bother with obvuscation? Server side code has no need for obvuscation, because it isn't being downloaded into the browser.
Three.js is open source. You can't steal what's for free. The "juicy effects" are assets that are run via three.js. Assets are copyrighted works. Copying them 1:1 makes one liable for litigation. It doesn't make sense to run 3d graphics on the server and stream them onto the client if you can run them on the client.
All they need to copy/paste obvuscated JS is a browser.
You're assuming that the code can be taken as-is, but something as esay as checking what domain it is running on and causing undesired behaviour if it's running on someone else's website could make this impossible.
Any scriptkiddie with the skill to "steal" scripts from some site can probably figure this out and remove it, but if the code is obfuscated, once again, it becomes easier to just write the code yourself in most cases.
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.
Right at the bottom there's a link to the FAQ for everyone to find it.
But here's the link after applying the 2 minute rule:
dev.to/guidelines-for-ai-assisted-...
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.
Yes. Merely emphasising your point. That extension looks definitely useful though! Thanks for sharing!
Good to know, thank you :D
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 👀