Wix sites come with a variety of features that make them quite secure by default. For instance, all Wix sites are validated with an SSL certificate, and they automatically use HTTPS, which uses public key encryption to ensure that the data transferred over your SSL connection is secure. Additionally, Wix employs security experts tasked with trying to hack the company’s systems to help strengthen and improve their defenses. The company also operates a bug bounty program that compensates engineers for finding security issues with their systems. Despite all of these built-in security features, adding custom code with Velo has the slight risk of introducing data leakages and other security risks. Fortunately, there are some precautions that can be taken to ensure your site is safe for visitors and website members.

Page Code and Code Files

Page Code files are front-end, client-side files that are specific to each page or element they’re connected to. Functions that you create in these files should be used for rendering elements on your page, or making modifications to the design of your site.

Global files are visible to any site visitor, and include the front-end (master.js) and public areas of your site’s code structure.

Code Files are considered part of the back-end of your site, and can include server-based functions, authentication methods, or any function that involves transmitting data. Code Files that load on the server side can help improve your site’s performance, since server-side files have faster load times than front-end, client-side code.

Securing it: It’s important to remember that code placed on password-protected pages and membership-only pages is still visible to any site visitor. Never place code related to Velo Forms, API fetches, and sign up or log processes on the front-end of your site, since these forms may contain personal information.

Developers can also use browser inspectors or testing tools that can expose additional data that you may not want others to see. It’s imperative that you place code related to sensitive data in the back-end area of your site where data and functions are secured and cannot be accessed by site visitors. Any code written in the front end of your site is public, so if there are secret API keys or if you are passing data into your function calls as a parameter, visitors will understand how data is transmitted or collected on your site, and will be able to use that information to their advantage.

Data validation should also not be public. Using an if-statement to validate your users’ passwords also runs the risk of potentially leaking information. For example,

 if( password == ”Password123” ){ export all the funds! }

Here, your users’ passwords are at risk of being exposed.

Using query strings or URL parameters to send data also puts your site at risk. Someone could easily manipulate the URL and gain access to private information. Hackers would be able to view valuable personal information from users including their usernames, passwords, birthdates, and more, leaving your users vulnerable to manipulation.

Keep these security measures in mind as we go more in depth to the back-end area.

Backend and Public Files

On the left side of the editor, you’ll find the Velo Sidebar, which will contain all of the code files for your site. Let’s focus on the curly brackets ({}) area labeled “Public & Backend.”

The Public area is for javascript(.js) files that are free of sensitive information. It can be a useful area for creating folders that you can reuse across your site to help organize your code. This is the place to store any code that requires access in the global scope, but you would also not want to run automatically on your site.

The Backend area is for JavaScript (.js) and web module(.jsw) files. This is the only place where you can write functions that are not exposed to site visitors. Because the backend is a private folder, you can only export functions from a .jsw.

Securing it: Store code in the backend that you don’t want your visitors to have access to. This can include API calls, verification processes, and personal information. Public JavaScript files are for usage across your site and don't contain private information.

Javascript Files and Web Modules

Within the Backend area of your site, you are able to write code within two file types.

.jsw (Velo web modules) files are exclusive to Wix and contain functions that can be imported to the front end of your site.

.js files cannot be accessed by front-end files, but can be accessible to other .js files within the backend folder or .jsw files.

Securing it: When writing multiple .jsw files in the back end of your code, it’s a good idea to place your functions in .js files to organize your code and export only the functions you need to your .jsw file. Any export functions you have in your .jsw will be accessible to any site visitor, even if the function is not being called.

Because site visitors can see the name of exported backend functions (even when unaware of what the function actually does), they can use this information to test and manipulate the function, making your site easier to hack. Adding a validation method inside of a new .js file within the backend can be a useful safeguard against this malicious action.

Setting Permissions for Web Modules

Wix automatically detects all of the functions in your backend file web modules. Within the back-end menu, you should see them all listed out. Hover over the ellipsis icon (...), you should see the option to “Edit Web Module Permissions”.

Securing It: You also have the ability to change who can invoke specific functions. By default, anyone can trigger any function. Fortunately, with the builtin Members API, you can make certain actions available only to administrators or to site members. Setting “Admin Only” permissions can be a great protective measure for specific events in which you want to allow anyone to become a site member. It’s also useful if you only want specific roles within your team to perform certain actions, such as deleting data, authenticating users, or limiting who has access to your site members and their data. Additionally, this can help you screen for malicious intent, especially when dealing with anonymous users who perform unwanted actions.

Takeaway

Wix allows you to add JavaScript files in multiple places. Each site is separated between front-end page files, back-end files, and global files. The back-end section is the most secure place, so that’s where you want to add parts of your code that have to do with personal information or API calls.Once you add your functions to a .jsw file, you can set even more specific permissions specifying that site members or administrators can invoke a particular function (since by default, anyone can trigger a function or has the ability to view potentially sensitive data). Keep this in mind the next time you want to add more functionality to your site and happy coding! To learn more about best practices for web security, check out this article.