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. Each permission should only be granted to the role unless there is a specific reason to grant the permission to additional roles. Even when there is a reason to grant a permission to more roles, you should only grant it to the roles that need it. Admin Here are some examples to illustrate this point: 1. Form Submission - Suppose you have an input form that you want anyone to be able to use. On the collection that the form is connected to, you need to set the permissions to the role. But you should still keep all the other permissions restricted to only the role. create Anyone Admin Read - Admin Create - Anyone Update - Admin Delete - Admin 2. Site Content - Suppose you have a page that displays content from a collection to anyone. You need to set the permission of that collection to the role. But you should still keep all the other permissions restricted to only the role. read Anyone Admin Read - Anyone Create - Admin Update - Admin Delete - Admin 3. Member-Generated Content - Suppose you have a member-generated comments section where members can post comments that anyone can see, but only the poster can update or delete the comment. You should to set the permissions as follows. Read - Anyone Create - Site member Update - Site member author Delete - Site member author The collection permissions model contains a number of presets that automatically set the permissions for common scenarios, such as the ones mentioned above. For more information on the roles and presets, see and in . Roles Collection Type Presets About Database Collection Permissions You should be careful when granting a permission to your collections even if you don't expose that collection functionality in your site. Here are some examples to illustrate this point: If your site does not contain a form for users to create content for a specific collection, you may think you can safely grant the permission for that collection to be . That is not the case. Even though there is no form for a user to create content in the collection, a malicious user can still inject data into your collection. However, your collection will be protected if you restrict the permission to only the role. create Anyone create Admin 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 grant the permission for that collection to be . That is not the case. Even though there is no page that uses the collection, a malicious user can still read data from your collection. However, your collection will be protected if you restrict the permission to only the role. read Anyone read Admin Special Situations Sometimes, you may need to grant access to collection data only in a specific situation or only to a specific user. Changing the permissions of the collection will not work in such cases because doing so exposes the collection data to all users of with the permitted role all the time. Instead, you can set the collection permissions as appropriate for most situations. When you need a user with a different role to access the collection in some manner, you can perform that operation in code. Backend When calling certain functions from the backend, you can use a object to suppress the permissions check when running the operation. So, even though your collection permissions are restricted to the role, you can perform whatever operation you need, even though the current user's role hasn't been granted permissions for that operation. However, keep in mind that exported backend code can be called by anyone, as described below. wix-data WixDataOptions Admin Therefore, a backend function that suppresses permissions checks  must perform its own appropriate checks before accessing the collection. Also, only suppress permissions checks when absolutely necessary. When not needed, the permissions checks will ensure that even backend operations run only for users who have been granted permission to that operation. Code Visibility All , , and code is visible to any user who visits your site. Even code on a or can be viewed and manipulated by site visitor, even those who don't have the password and are not members. Page Site Public Page password-protected page members-only page any Therefore, it is extremely important that you don't expose any sensitive information in , , or code. Page Site Public code is not visible to site visitors. So it's safe to use sensitive information there. However, keep in mind that even though malicious visitors can't see what exported backend functions do, they can still see they exist, call them with any arguments they want, and examine their return values. Backend Therefore, any exported backend code should contain some sort of validation mechanism before performing 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 . Never use API keys in , , or code. Secrets Manager Page Site Public Instead, create a function in a that uses the to extract the key and .  Then call that function from your , , or code. backend web module Secrets API calls a 3rd party service Page Site Public Validations and Checks If you want to perform a security check or validation in your code, you should always do so using code. Any check or validation in your , , or code can be easily read, manipulated, and circumvented by a malicious site visitor. Backend Page Site Public For example, consider the following code intended to reveal a secret key to a specific user: Page {
  wixUsers.currentUser.getEmail()
    .then( { (userEmail === ) { $w( ).text = ;
      } { $w( ).text = ;
      }
    } );
} export ( ) function validateButton_click event => userEmail if "secretEmail@mail.com" // show secret key "#secretText" "43ne5gfou94tfe" else // show denial message "#secretText" "Access denied!" There are two major problems with this code: The security check is revealed to all site visitors. Anyone can see that the correct email address is . secretEmail@mail.com 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: wixUsers ; {getSecret} ; { { currentUser = wixUsers.currentUser; currentUserEmail = currentUser.getEmail(); secretEmail = getSecret( ); (currentUserEmail === secretEmail) { secretValue = getSecret( ); secretValue;
    } { ;
    }
  } (err) { .error(err); ;
  }
} // In backend file: secureModule.jsw import from 'wix-users-backend' import from 'wix-secrets-backend' export async ( ) function secureCheck try const const await const await "secretEmail" // "secretEmail@mail.com" if const await "secretValue" // "43ne5gfou94tfe" return else return "Access denied!" catch console return "An error occured" Although malicious users can call the backend function, they can't gain any information by doing so since no sensitive information has been revealed. You can call this function safely from code as follows: Page {secureCheck} ; {
  secureCheck()
    .then( {
      $w( ).text = message;
    } );
} import from 'backend/secureModule' export ( ) function secretButton_click event ( ) => message "#secretText" This page code is visible to any site visitor. However, since all the logic was moved to backend code, seeing the code doesn't reveal any sensitive information to malicious users. Web Module Permissions You can also set permissions that define who can call each individual exported function in a web module. To learn more, see . About Web Module Permissions Storing Personal Information in a Collection You can store your site visitor's personal information in a collection, provided that you set the collection permissions so that only the can , , or content. Site member author read update delete You may also want to store visitor's information using the built-in . This will allow you to use this information with all the other functionality that Wix provides for use with your contact list. Contact List You can then also use Velo APIs for performing operations that involve site members or contact data. The following APIs are available: wix-crm wix-crm-backend wix-users wix-users-backend Previously published at https://support.wix.com/en/article/velo-security-best-practices

Different

Keep

Mind

Creating and Debugging Website Routers 

How To Avoid SEO Pitfalls

Develop Smarter, Deliver Faster

Read My Stories

Too Long; Didn't Read

Boost your HackerNoon story @ $159.99! 🚀

Velo How-To: Security Checklist

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

5 Hot Velo Practices to Test and Debug Your Website Code

10 Cool CI/CD Tools For Your Project

27 Stories To Learn About Ssl

20 Essential Backend Tools For Developers

3 Most Common Ways to Connect your Node and React Applications

5 Hot Velo Practices to Test and Debug Your Website Code

10 Cool CI/CD Tools For Your Project

27 Stories To Learn About Ssl

20 Essential Backend Tools For Developers

3 Most Common Ways to Connect your Node and React Applications

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps