How to properly deploy Webix UI for production and prevent users from calling $$() in console

Webix JS
1

I’m preparing my Webix UI app for production and would like to know the best practices for deployment.

  1. What’s the recommended way to build/minify Webix apps for production?
  2. How can I prevent users from opening the browser console and calling $$('viewId') or other functions to manipulate data directly?
  • Is there a safe or official way to disable or hide $$() in production builds?
  • Would deleting window.$$ after init cause issues?
2

We’ll wait for the official answer, but it seems to me that anything that runs in browser is accessible via console. Webix is just UI. So the task of securing the app is for the authorization and backend, but changes to the UI, like $$(“someLabelId”).setValue(“haha”) are runnable, those kind of changes you can’t prevent. What you can do, is secure the backend and do not save unwanted changes.

  • Would deleting window.$$ after init cause issues?

Most probably yes.

3

Hello @Supawit_Nu-iat ,

  • It is recommended to include webix.min.js directly in your final build instead of linking it separately. This ensures that both Webix and your application code are bundled together.

If you obfuscate only your code and connect Webix separately, you can only connect these two files if you have source maps of its code—and this allows you to completely parse it and kills the idea of ​​hiding everything.

  • Obfuscate your entire build to enhance security. Obfuscation is essentially just another layer of name changes and transformations, resulting in valid JavaScript that is still functional but harder to read.
    It is not advisable to delete or disable the $$() function in production. Doing so can cause issues since it is part of Webix’s public API. Instead, you can obfuscate the function name (e.g., transforming window.$$ into something like window._tr) to make it less recognizable while keeping it functional.

Note that while the method will still be accessible, it will not correspond to the public Webix API, adding a layer of obscurity.

  • Do not include source maps in your production build. Source maps can expose your original code structure and make it easier for someone to break down your app.
  • If you need to use the non-minified version of Webix for any reason, consider creating a custom build that removes debugging features. This can help you avoid exposing additional functionalities that could be exploited.
    For example, in the GPL version on GitHub, here’s what you’ll need to remove: Webix Source Code.
1 Like