Velo: Security Best Practices

In general, your site is secure without you having to do anything. Wix takes care of that for you. However, there are certain situations where you have to take some precautions so that you don't expose your sensitive data to your site's visitors.

Collection Permissions

You should always set the permissions of your database collections to be as restrictive as possible. Generally, permissions for a collection should be granted for the Admin role only, unless there is a reason to grant a specific permission for additional roles. Even when there is a reason to grant a permission for more roles, you should only grant it for the roles that need it.

Here are some examples:

The collection permissions model contains a number of presets that automatically set the permissions for common scenarios, such as the ones mentioned above.

Unused Permissions

Be careful when granting a permission to a collection even if you don't expose that collection’s functionality in your site.

Here are some examples:

• **Unused create permission

  **If your site doesn’t contain a form for site visitors to create content for a specific collection, you may think you can safely set the create permission for that collection to Anyone. That is not the case. A malicious site visitor can inject data into your collection without a form. Make sure your collection is protected by restricting the create permission to the Admin role.

• **Unused read permission

  **If you have a collection for internal use that you don't use on any of your site's pages, you may think you can safely set the read permission for that collection to Anyone. That is not the case. A malicious site visitor can still read the data from this collection. Make sure your collection is protected by restricting the read permission to the Admin role.

Temporarily Bypassing Collection Permissions

Sometimes, you may need to grant access to collection data only in a specific situation or only to a specific user. You may need to expose some of the data in a collection, while keeping the rest private. In these cases, extending the permissions of the collection to more users is a security risk. Doing this exposes all the collection data to users with the permitted roles all the time. Instead, set the collection permissions as appropriate for most situations. Then, when you need to grant access to the collection to a specific user or for a specific use case, perform that operation in backend code.

You can grant temporary access to collections using the suppressAuth parameter that’s available as an option for many Wix Data functions. Setting suppressAuth to true allows a data request in backend code to interact with a collection even if the site visitor requesting the data doesn’t have permission to access that collection. To grant temporary access to a collection, define a function in your backend code that makes a data request using suppressAuth. Export this function for use in your frontend code.

Here are 2 examples of using suppressAuth to grant specific and temporary access to collection data:

• **Access for site members with specific roles

  **Wix allows you to create custom roles for site members. However, you currently can’t set collection permissions by role. To allow only members with a certain role to access a collection, set the collection’s permissions to Admin. Then, implement backend code that suppresses permission checks for site members with the desired role.

• **Access to specific collection fields

  **Some collections contain both private and public data. In this case, you may want to expose the public data to site visitors while keeping the private data secure. To do this, set the collection’s permissions to Admin. Then, implement backend code that suppresses permission checks and returns only the public data.

Storing Personal Information in a Collection

You can store a site visitor’s personal information in a collection, provided that you set the collection permissions so that only the Site member author can read, update, or delete content.

You may also want to store visitor information using the built-in Contact List. This allows you to use this information with all the other contact list functionality that Wix provides. You can then also use Velo APIs to perform operations that involve site members or contact data.

The following APIs are available:

• wix-crm-frontend
• wix-crm-backend
• wix-members-frontend
• wix-members-backend

Signup Forms

When you set up a member signup form for your site, you have 2 options for limiting who is allowed to sign up:

• Everyone: When a new member signs up, they are approved automatically. You do not need to do anything.
• People I approve: When a new member signs up, you receive a notification, both by email and in your site's dashboard, asking if you want to approve or reject them. Only those who you approve become site members.

If your site members have permissions for any of the collections on your site, then choosing Everyone is the same as setting those permissions to Anyone. This is because anyone can now become a site member and use the site member permissions. This is a potential security concern. You should think carefully about whether site members have access to any sensitive collection information before allowing anyone to become a member.

Code Visibility

All Page,  Public, and masterpage.js code is visible to any site visitor. Even Page code on a password protected page or members only page can be viewed and manipulated by any site visitor, including those who don't have the password and are not members. Therefore, it’s extremely important that you don't expose any sensitive information in Page, Public, or masterpage.js code.

Backend code isn’t visible to site visitors. It's safe to use sensitive information there and export the results to frontend code. However, even though malicious visitors can't see what exported backend functions do, they can still call those functions if they know their names.  They can do this using any arguments they want, and examine any return values. Therefore, any exported backend code should perform validations before carrying out potentially harmful operations or returning sensitive information. Also, backend functions that are not called from public code should not be exported.

API Keys

If you access a 3rd party service that requires an API key or other sensitive information, you should always store that information in the Secrets Manager. Never use API keys in Page, Public, or masterpage.js code. Instead, export a function from a backend web module that uses the Secrets API to extract the key and calls the 3rd party service. Call that function from your Page, Public, or masterpage.js code.

Velo Signup and Login Forms

If your site has a Member's Area, you can add forms using Signup & Login pages. One type of form you can add is a Velo Form, which lets you use code to customize member signup and login. Because signing up and logging in involve the transfer of sensitive information, it’s best to prevent signup & login API calls from running in the frontend when using a Velo Form.

Validations and Checks

If you want to perform a security check or validation in your code, you should always do so using Backend code. Any check or validation in your Page,  Public, or masterpage.js code can be easily read, manipulated, and circumvented by a malicious site visitor.

For example, consider the following Page code intended to reveal a secret key to a specific site visitor:

There are two major problems with this code:

1. The security check is revealed to all site visitors. Anyone can see that the correct email address is [email protected].
2. Sensitive information is revealed to all site visitors. Anyone can see that the secret code is 43ne5gfou94tfe. 

The correct way to do this is to move both the security check and the secret code to a backend web module as follows:

Although malicious site visitors can call the backend function, they can't gain any information by doing so since the function doesn’t reveal any sensitive information. You can call this function safely from Page code as follows:

This page code is visible to any site visitor. However, since all the security check logic was moved to backend code, seeing the code doesn't reveal any sensitive information to malicious site visitors.