About HTML encryption obfuscation, source code protection, code security, preventing decompression and viewing the source code directly_html/css_WEB-ITnose

Some people have been asking how to obfuscate HTML encryption. In fact, this is a topic that has been studied by many people in the industry.

I recently compiled an article to share with you in my spare time.

Let’s first sort out the requirements. What is the purpose of encryption? What level of encryption is it? What can we sacrifice for this?
We know that there is no absolute security in this world, encryption will be cracked, and obfuscation will be deobfuscated.
Technical novices, developers, and hackers are all at completely different levels, and the strategies for preventing people at different levels are different.
The greater the prevention efforts, the greater the investment cost, such as hiring a professional security company.
In addition to investment, we also need to consider the execution performance and user experience of the program.
Encrypted code must be decrypted at runtime. After obfuscation, especially after obfuscating HTML, the execution performance of the program will decrease.
Whether this type of source code protection is really necessary requires careful decision-making.

Generally speaking, the front-end code is responsible for user experience, and the back-end code is responsible for safer data processing.
The front-end should not involve leaking too much confidential information, so the meaning of encryption is not particularly significant.
I rarely see content worth protecting in front-end code, such as advanced algorithms. There is no need to sacrifice user experience to protect many codes.
However, some front-end codes involve end-user data security, so efforts should still be made to protect data at this time.

Next, we will analyze several methods in detail.

1. Don’t put sensitive data on the front end
   This sounds nonsense, but it’s really important.
   Some developers store user passwords in plain text on mobile phones, which is very dangerous.
   Even if it is native development, once the phone is rooted, data leakage will occur. Not to mention HTML5 development.
   A better approach is to store tokens on the mobile phone instead of passwords. Here is an article dedicated to this. Developers involved in login are recommended to take a closer look at how to design the APP login function and secure calling interface based on HTML5 ( Principles)

1. js, css compression
   Compression is not encryption, nor obfuscation. But compressed js files often also have obfuscation functions.
   JS and CSS compression are very common technologies. We often see that the file names of various frameworks are xxx.min.js and xxx.min.css.
   Using appropriate js and css compression solutions can reduce file size, improve loading speed, and most importantly, it can also speed up program execution performance. It is simply a benefit without any harm.
   The most commonly used tool to obfuscate js is Yahoo's YUI obfuscation. Click the menu tool-plugin installation in HBuilder. There is YUI compress in it, which can compress js and css.
   If js and css are relatively large, it is recommended to compress them before publishing.

1. Confusing HTML, js, css
   Although compression can also be confusing, it is not for the purpose of making others incomprehensible. Confusion is really for the purpose of others not being able to understand.
   But such confusion is not as harmless as compression. It will reduce program execution performance.
   Some developers do not want to see the source code directly after decompressing the distribution package, so they can use the obfuscation solution at this time.
   Searching for HTML obfuscation on the Internet, there are a lot of information and tools.
   The principles are similar. The js code turns into a messy string and is then executed using eval. The HTML code turns into a messy string and is executed using document.write or innerHTML. CSS can also be dynamically written in document.write