Angular-cli: Code protection by obfuscation in particular environment

Created on 19 Oct 2017  路  6Comments  路  Source: angular/angular-cli

Bug Report or Feature Request (mark with an x)

- [ ] bug report -> please search issues before submitting
- [x] feature request

Versions.


@angular/cli: 1.2.5
node: 7.9.0
os: win32 x64
@angular/animations: 4.4.4
@angular/common: 4.4.4
@angular/compiler: 4.4.4
@angular/core: 4.4.4
@angular/flex-layout: 2.0.0-beta.9
@angular/forms: 4.4.4
@angular/http: 4.4.4
@angular/material: 2.0.0-beta.7
@angular/platform-browser: 4.4.4
@angular/platform-browser-dynamic: 4.4.4
@angular/router: 4.4.4
@angular/cli: 1.2.5
@angular/compiler-cli: 4.4.4
@angular/language-service: 4.4.4

Desired functionality.

Add new options to the cli under 'build' and 'serve' tasks to obfuscate a code while being able to debug it using sourcemaps.
As a developer i should have the ability to obfuscate part / all of the code by the following categories in order to protect my code in specified environments - like in production:

  • Js code (all the chunk files that webpack creates)
  • stylesheets (rename stylesheet from something meaningful to something else that is minified to as much less characters as possible for instance - class name: "app_toolbar" will be replaced to "Ax" - base64 maybe bigger table to produce less characters?)
  • Component / Directive names - thats something that could be unique to Angular itself, renaming the name of the components inside the app tree without loosing functionality and still be able to debug.

Mention any other details that might be useful.

Currently im using gulp as a separate process after ng build to obfuscate JS code and its pretty much easy and it works, webpack also has plugin for that but i dont want to eject all angular cli webpack configurations and lose the support of this library.

There is an awesome library for JS obfuscation:
https://github.com/javascript-obfuscator/javascript-obfuscator
I think it will be nice if you can also add options to the obfuscation itself like domain lock.
All that options can be added to .angular-cli.json file.

Google has opensource for obfuscation and minification to JS/CSS:
https://developers.google.com/closure/compiler/

RFC / discussion / question feature

Most helpful comment

Understood, I just wanted to clarify the inclusion of closure in the conversation and that the CLI does use a similar tool.

However, realistically if someone is willing to spend the time and resources to reverse engineer code run through uglifyjs, then barring some full encryption DRM based system (potentially with a custom web browser), they're must likely going to figure out how your code works. They most likely know what libraries the application is using and what it looks like in the web browser and can use the web browser devtools to explore and manipulate the app. It's also quite likely that someone will eventually make a tool that un-obfuscates the source that is generated by the above linked tool. The original source code wouldn't be regenerated but it would make anything more than just using a minifier fairly moot. And at that point it's really just a race to the bottom in terms of the cost to the app's performance and size. In fact the tool itself mentions that currently performance is degraded between 15-80% and has a large increase in file size. If the application is hard to access and slow for end users, having someone reverse engineer the code is probably not going to be the main problem for the application.

There are cases were code protection is a primary project goal. In those cases the use of a SPA itself may not be the best choice and a server based web framework may be more appropriate. Either way, a well thought-out overall system architecture is critical to ensure a clean separation of presentation code (which is sent to the end user) and application logic (which stays behind an access controlled server).

All 6 comments

@lihaibh I think we just have to be patient here until the very promising ABC Angular Labs solution lands.

Closure's primary purpose is size reduction; obfuscation is really a side effect of that process (i.e., shorter names equals a smaller file size).
In regards to the CLI, production builds minify the code via UglifyJS which while not as effective at size reduction as Closure is still quite good (and faster).

@clydin that's right but sometimes you want to makes the code even harder to understand deliberately and there are many ways you can achieve that for example: changing string names to base64 or locking the code from running when it's modified or run under different origin all of those features an obfuscation library is able to do unlike uglifyJs that makes the source code to be optimized. though optimized code may seems to be unreadable for the common developer, its main goal is improving performance to the end user, obfuscated code main goal on the other hand is to make it so that end users can not reverse engineer Javascript source code and use it for their own projects, atleast not easily.

Understood, I just wanted to clarify the inclusion of closure in the conversation and that the CLI does use a similar tool.

However, realistically if someone is willing to spend the time and resources to reverse engineer code run through uglifyjs, then barring some full encryption DRM based system (potentially with a custom web browser), they're must likely going to figure out how your code works. They most likely know what libraries the application is using and what it looks like in the web browser and can use the web browser devtools to explore and manipulate the app. It's also quite likely that someone will eventually make a tool that un-obfuscates the source that is generated by the above linked tool. The original source code wouldn't be regenerated but it would make anything more than just using a minifier fairly moot. And at that point it's really just a race to the bottom in terms of the cost to the app's performance and size. In fact the tool itself mentions that currently performance is degraded between 15-80% and has a large increase in file size. If the application is hard to access and slow for end users, having someone reverse engineer the code is probably not going to be the main problem for the application.

There are cases were code protection is a primary project goal. In those cases the use of a SPA itself may not be the best choice and a server based web framework may be more appropriate. Either way, a well thought-out overall system architecture is critical to ensure a clean separation of presentation code (which is sent to the end user) and application logic (which stays behind an access controlled server).

Closing as per @clydin explanation.

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_This action has been performed automatically by a bot._

Was this page helpful?
0 / 5 - 0 ratings