Does web front-end JS code need protection? How to protect web front-end JS code

Does the Web front-end JS code need to be protected?

This requires detailed analysis of the specific situation.
1. If you just write a simple function such as a web page image carousel, or a marquee effect, etc. That doesn't require protection.
2. If you are carefully designing a gorgeous special effect, and if you want to protect the special effects code that you have worked so hard to implement from being used by others at will, then you should protect this JS code!
3. If there are important functions on the page that are controlled by JS code, such as transaction logic, account and password information, personal privacy, and even communication with remote servers or databases, etc., then the relevant JS code should be Protection, JS code anti-theft protection should be done!
Otherwise, it may cause serious problems such as analysis and attack by hackers. Safety-related matters must always be nipped in the bud and not left to chance. Unless it doesn't matter to you at all.

How to protect web front-end JS code?
1. Packaging & Compression
Some people think that packaging and compression are the protection of JS code. Indeed, packing can at least provide some protection to a certain extent, as it seems. However, the purpose of packaging and compression is not to protect JS code, but to facilitate use, reduce code size, facilitate use, and facilitate transmission. For example, modular programming may produce 200 JS files. If you use "script src" to reference each one one by one... this is a kind of torture, whether it is for the agent or the network loading (the browser will also be angry! x_x).
Similar to Webpacket and Gulp packaging, these multiple JSs can be synthesized into one file, and carriage returns, line feeds, and spaces may be deleted to achieve code compression. There are also some simple obfuscation operations: changing long variable names For short variable names in a unified style, etc. Then, a file is finally generated. The total amount of code is reduced, the readability is poor, and it is easier to use. At the same time, some people think that this also achieves JS code protection. In fact, in fact, of course, the code is not protected: the readability is still the same, but the amount of code is larger. As long as you read the code with a little patience, you will find that the code is still easy to understand, and there is not much security at all. .
2. Obfuscation & Encryption
To protect the front-end JS code, obfuscation and encryption must be combined.
Separate JS source code encryption is not feasible, let alone the so-called JS irreversible encryption. Because when the code is executed on the browser side, it must be decrypted and restored to the original code before it can be recognized and run by the browser's JS engine. After decryption, the complete original JS code will exist. This is very unsafe and there are many ways to display the original JS code.
JS code obfuscation is considered by many developers to be a low-end JS code protection method, and it sounds less secure than JS source code encryption. In fact, there are multiple levels of obfuscation. For example, relatively low-end character search and string replacement, random insertion of pseudo-zombie code, string hexadecimalization, etc. There are also high-end methods that will first perform syntax analysis, lexical analysis, and reconstruct the syntax tree. This is equivalent to having implemented a JS engine and processing the code in the engine. Then, you can perform operations with a high degree of freedom in any step. For example, new syntax structures can be inserted into the syntax tree, all strings can be extracted and encrypted, variables can be redefined in a regular manner to make them meaningless, etc. This allows for true code reconstruction. The security of the JS code reconstructed in this way will be qualitatively improved.
When true obfuscation and encryption are used together, such as JShaman JS protection, can achieve real JS code security protection. JS encryption is integrated into JS obfuscation, and JS obfuscation is embedded into JS encryption. Even if the code protected in this way is reverse-restored in the client execution environment, a large number of functions, codes, and strings with unknown meanings will be obtained. The special point is: the code has been reconstructed, and what you get by reverse engineering is also the separated and reconstructed meaningless JS code, a large number of zombie codes, confused strings, and variables with unknown meanings. The readability compared to the original code is...a world of difference.
Stubborn people may also say: There is no protection solution that cannot be cracked. As long as I analyze it carefully, attentively, and take time, I can still analyze the meaning of the original code. Indeed, this may be the case.
However, it may only take 10 minutes to read the original code, but it may take... 10 months to read the original meaning from the protected JS code. At this time, our JS code may have been updated to the next version.
The purpose of JS code protection has been achieved, hasn’t it?

Related recommendations:

Web front-end code specification

##web front-end development upload upload avatar js sample code

The above is the detailed content of Does web front-end JS code need protection? How to protect web front-end JS code. For more information, please follow other related articles on the PHP Chinese website!