Front-end source code security

Today think about the front-end source security things (not the front-end security, just for the source code section). In my opinion, the source code security has two points, one is to prevent plagiarism, the second is to prevent the breach. In fact, the front-end code is mostly no plagiarism, security is the same as a fake (any front-end input can not be trusted). But if you still want to prevent the source code to be viewed, HTML, CSS and can not do anything, the end will be exposed (the simplest with the chrome developer tools can be seen), so only for JS file compression merging and confusion.

About plagiarism

In fact, the front-end, the code is nothing good plagiarism, most people are copied UI design (this is not to hide), there are some rich front-end control and algorithm, the important point is still in the back end, the back end is not copied. So the front-end file compression merge, the purpose is not to prevent plagiarism, but to reduce file size, speed up loading speed, improve the execution performance of the program, of course, compression also has confusing function. File obfuscation is to prevent others from viewing the code logic, but the generated code is much larger than the original code, so if the file is confused, the load speed and execution speed will decrease.

About security

All user input can not be trusted, if the back end of the check is not done well, it can be compromised. The logic of the front-end code, if it is understood clearly, is worse. Back end of the problem of our front-end, the front-end code security, simple can be used to solve the compression, and then further to confuse, so that others do not understand.

HTML compression

Few people do HTML compression (specifically to remove whitespace characters and comments), depending on the other data for several reasons:

1. In an HTML document, multiple whitespace characters are equivalent to one white space character. This means that the deletion of whitespace characters such as line breaks is unsafe and may cause differences in the style of the elements.

2. In the HTML element, there is a pre that represents preformatted text. Any blank inside, can not be deleted.

3. There may be an IE conditional comment in the HTML. These conditional comments are part of the document's logic and cannot be deleted.

In view of the above reasons, do not promote the compression of HTML, gzip compression has been able to achieve good results.

CSS compression Merge

CSS compression merging is common, or required, and can be generated dynamically by the backend or by a tool in advance. The purpose is only to increase the loading speed, CSS even after compression, the code is clearly visible, there is no confusion. CSS compression combined with a lot of tools, generally with sass, less directly generated after the compression of the CSS, if it is directly compressed, with Grunt is good.

JS Compression Merge Confusion

In a production environment, compression merging is a must-do. As stated above, the purpose is not to prevent exposure to business logic, but to increase loading speed. In the previous article "Angularjs combined with Requirejs to do the file merge compression of those pits," said a little JS compression merger to pay attention to things. In addition to using REQUIREJS, direct use of grunt to publish is a good way to develop a key after the call grunt.

Grunt need to configure two files:

Package.json: Declaring app information and using a dependent library version

{    "name": "Bingotouch",    "version": "3.0.0",    "engines": {        " Node ":" >= 0.8.0 "    },    " Devdependencies ": {        " grunt ":" ~0.4.0 ",         "Grunt-contrib-concat": "~0.3.0",        "grunt-contrib-copy": "~0.4.1",        " Grunt-contrib-cssmin ":" ~0.6.0 ",        " grunt-contrib-uglify ":" ~0.2.0 ",        " Express ":" "     }}

Gruntfile.js: Declaring a compressed merged file

Module.exports =function(Grunt) {Grunt.initconfig ({Pkg:grunt.file.readJSON (' Package.json '), concat: {' Dist/bingotouch.js ' :               [ ' Demo/js/ui.js ',                 ' Demo/js/module/ui. Garbagecollection.js ',                 ' Demo/js/module/ui.plugins.js ']}, Uglify: {target: {files: {' Dist/bingotouch.min.js ': ' Dist/bingotouch.js '                }            }        }     }); Grunt.loadnpmtasks (' Grunt-contrib-concat '); Grunt.loadnpmtasks (' Grunt-contrib-uglify '); Grunt.registertask (' Default ', [' concat ', ' uglify ']);}

JS confusion I have so far not used, the principle is similar, confusion is the JS code into a messy string, and then use the eval execution.

Ps:uglify itself has a certain confusion, but also only the variable name of the confusion, confusion and not enough.

Before confusion:

function Hello () {    alert (' hello ');}

After confusion:

Eval (function(p,a,c,k,e,r) {e=string;  If(! '). Replace (/^/,string)) {while (c--) r[c]=k[c]| | c;k=[function(e) {return r[e]}];e=function() {return' \\w+ '};c=1};  while (c--) if (K[c]) p=p.replace (new RegExp (' \\b ' +e (c) + ' \\b ', ' G '), k[c]); return

Different obfuscation algorithms confuse the results differently, and the confusion is not once and for all, or can be anti-confusing. In addition, confusion can degrade the performance of the program execution, so it needs to be confused to evaluate.

Summarize

I think a good file compression merge, simple variable name confusion can be, do not need to be so thoroughly confused. Even if the front end is dug clearly, as long as the back-end strong also no problem. So when you want to confuse the code, think about what it is worth.

This article for the original article, reproduced please retain the original source, convenient traceability, if there is the wrong place, thank you correct.

This address: http://www.cnblogs.com/lovesong/p/5185543.html

Front-end source code security