Security Best Practices

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

Collection permissions

If you are using custom collections you should always set the permissions of your database collections to be as restrictive as possible. If the collection contains sensitive data such as PII or secrets, the Read permissions 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.

Also, to prevent anyone from removing or updating the data, you should set the Update and Remove permissions to the Admin role. Or, if there is a UX flow for users to update or remove the data, then you can set those permissions to Site member author.

Here are some examples:

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 bypass 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. See About Collection Permissions for more information.

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.v2
• wix-crm-frontend
• wix-crm-backend
• wix-members.v2
• 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 enabling automatic approval of new members sign up is the same as setting those permissions to collections 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 and public code is visible to any site visitor. Note that page code on a password protected page or members only page can be viewed by any site visitor, including those who don't have the password and are not members. Therefore, don't expose sensitive information in page or public code, including in the masterpage.js file.

Backend code is not 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 from .web.js or .jsw files.

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.

Signup and login forms

If your site has a Member's Area, you can add forms using signup and login pages. One type of form you can add 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 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 secretEmail@mail.com.
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.

See also

• About Web Modules
• About Collection Permissions