> Portal Navigation:
>
> - Append `.md` to any URL under `https://dev.wix.com/docs/` to get its markdown version.
> - Pages are either content pages (article or reference text) or menu pages (a list of links to child pages).
> - To get a menu page, truncate any URL to a parent path and append `.md` (e.g. `https://dev.wix.com/docs/sdk.md`, `https://dev.wix.com/docs/sdk/core-modules.md`).
> - Top-level index of all portals: https://dev.wix.com/docs/llms.txt
> - Full concatenated docs: https://dev.wix.com/docs/llms-full.txt
## Resource: Security Best Practices
## Article: Security Best Practices
## Article Link: https://dev.wix.com/docs/develop-websites/articles/best-practices/security-best-practices.md
## Article Content:
# 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:
|Example |Recommended permission settings |
|---|---|
|**Scenario: Form submission**
An input form that you want anyone to be able to use.
**Solution**
On the collection that the form is connected to, set the **create** permissions to the **Anyone** role. Keep all the other permissions restricted to the **Admin** role.|Read: Admin
Create: Anyone
Update: Admin
Delete: Admin
|**Scenario: Site content**
A page that displays content from a collection to anyone.
**Solution**
Set the **read** permission of that collection to the **Anyone** role. Keep all the other permissions restricted to the **Admin** role.|Read: Anyone
Create: Admin
Update: Admin
Delete: Admin
|**Scenario: Member-generated content**
A member-generated comments section where members can post comments that anyone can see, but only the poster can update or delete the comment.
**Solution**
Set each permission based on who needs to access it.|Read: Anyone
Create: Site member
Update: Site member author
Delete: Site member author
## 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](https://www.wix.com/velo/reference/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](https://support.wix.com/en/article/collection-permissions-an-overview) for more information.
>**Note**
> * A backend function that suppresses Wix Data's permissions checks must do at least one of the following:
> (a) Perform its own checks before accessing a collection.
> (b) Filter out sensitive collection data before passing anything back to frontend.
> Anyone can call exported backend code, as described [below](https://dev.wix.com/docs/develop-websites/articles/best-practices/security-best-practices.md). This code therefore presents a serious security risk.
> * Only suppress permission checks when absolutely necessary. Leave Wix Data’s permissions checks enabled as much as possible. This way, even backend operations run only for users who have been granted permission for that operation.
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.
Show me how
This code defines two functions:
* **isPermitted()** : Uses the [Wix Members API](https://dev.wix.com/docs/velo/api-reference/wix-members-backend/introduction.md) to check if a site member has a Staff role
* **queryCollection()** : Uses suppressAuth to return a collection's data if isPermitted() returns true.
```javascript
import { Permissions, webMethod } from 'wix-web-module';
import { currentMember } from 'wix-members-backend';
import wixData from 'wix-data';
const isPermitted = webMethod(Permissions.Anyone, async () => {
try {
let hasPermittedRole = currentMember.getRoles()
.then((roles) => {
const staffRoleCheck = roles.filter(obj => obj.title === 'Staff');
if (staffRoleCheck.length > 0) {
return true;
} else {
return false;
}
})
return hasPermittedRole;
} catch (error) {
console.error(error);
return false;
}
});
```
```javascript
export const queryCollection = webMethod(Permissions.Anyone, async () => {
const accessGranted = await isPermitted();
if (accessGranted) {
try {
let collectionData = wixData.query('myCollection')
.find({ suppressAuth: true });
return collectionData;
} catch (error) {
console.log(error);
}
} else {
return "Access denied";
}
});
```
* **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.
Show me how
This code uses `suppressAuth` to query a collection and returns only the '\_id' and 'comment' fields.
```javascript
import wixData from 'wix-data';
export function getData(){
return wixData.query("myCollection")
.find({"suppressAuth": true})
.then((results) => {
if (results.totalCount > 0) {
const filteredResults = results.items.map( (item) => {
return {"\_id" : item.\_id, "comment" : item.comment}
})
return filteredResults
}
})
.catch((error) => {
console.log("Error:", error.message);
});
}
```
## 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](https://support.wix.com/en/article/about-your-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](http://www.wix.com/code/reference/wix-crm-v2.html)
* [wix-crm-frontend](http://www.wix.com/code/reference/wix-crm.html)
* [wix-crm-backend](http://www.wix.com/code/reference/wix-crm-backend.html)
* [wix-members.v2](https://www.wix.com/velo/reference/wix-members-v2)
* [wix-members-frontend](https://www.wix.com/velo/reference/wix-members)
* [wix-members-backend](https://www.wix.com/velo/reference/wix-members-backend)
## Signup forms
When you [set up a member signup form](https://support.wix.com/en/article/site-members-editing-the-signup-settings-for-the-default-and-custom-forms#customizing-your-default-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](https://support.wix.com/en/article/wix-editor-password-protecting-a-specific-page-of-your-site) or [members only page](https://support.wix.com/en/article/studio-editor-using-the-members-area#showing-exclusive-member-only-content) 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](https://dev.wix.com/docs/develop-websites/articles/best-practices/security-best-practices.md#validations-and-checks) 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](https://dev.wix.com/docs/develop-websites/articles/workspace-tools/developer-tools/secrets-manager/about-the-secrets-manager.md). Never use API keys in page, public, or `masterpage.js` code. Instead, export a function from a [backend web module](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/web-modules/call-backend-code-from-the-frontend.md) that uses the [Secrets API](https://dev.wix.com/docs/velo/api-reference/wix-secrets-backend/introduction.md) to extract the key and [calls the 3rd party service](https://dev.wix.com/docs/velo/apis/wix-fetch/introduction.md). Call that function from your page, public, or `masterpage.js` code.
## Signup and login forms
If your site has a [Member's Area](https://support.wix.com/en/article/site-members-about-the-members-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](https://dev.wix.com/docs/develop-websites/articles/code-tutorials/wix-members/creating-a-custom-registration-form-with-code.md). 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](https://support.wix.com/en/article/velo-backend-signup-and-login#security-implications) 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:
```javascript
import { currentMember } from 'wix-members-frontend';
$w.onReady( () => {
$w('#validateButton').onClick( () => {
currentMember.getMember()
.then((member) => {
if(member.loginEmail === 'secretemail@mail.com') {
// show secret key
$w('#secretText').text = '43ne5gfou94tfe';
} else {
// show denial message
$w('#secretText').text = 'Access denied!';
}
})
})
});
```
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:
```javascript
// In backend file: secureModule.web.js
import { Permissions, webMethod } from 'wix-web-module';
import { currentMember } from 'wix-members-backend';
import { getSecret } from 'wix-secrets-backend';
export const secureCheck = webMethod(Permissions.Anyone, async () => {
try {
const member = await currentMember.getMember({ fieldsets: ['FULL'] });
const memberEmail = member.loginEmail;
const secretEmail = await getSecret("secretEmail"); // "secretemail@mail.com"
if (memberEmail === secretEmail) {
const secretValue = await getSecret("secretValue"); // "43ne5gfou94tfe"
return secretValue;
} else {
return "Access denied!";
}
} catch (err) {
console.error(err);
return "An error occurred";
}
});
```
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:
```javascript
import { secureCheck } from 'backend/secureModule.web';
$w.onReady(() => {
$w('#secretButton').onClick(() => {
secureCheck()
.then ((message) => {
$w('#secretText').text = message;
});
})
});
```
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.
>**Note**
> You can also [set permissions](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/web-modules/about-web-modules.md#permissions) that define who can call each individual exported function in a web module.
## See also
+ [About Web Modules](https://dev.wix.com/docs/develop-websites/articles/coding-with-velo/backend-code/web-modules/about-web-modules.md#permissions)
+ [About Collection Permissions](https://support.wix.com/en/article/cms-collection-permissions-overview)