Security & Privacy


Make sure that your app is secure and protects the user’s privacy. We’ll go over the basics below.

During the app review, we may raise additional security issues that are relevant specifically to your app. 
Verify the User’s Identify
  • When Wix calls your app endpoint, check (on the server side) that the signature was signed by Wix. Here’s how to do that (you can also check out these parsing examples):
    • Take the data part of the instance parameter and sign it using your secret key. Let’s call this value “A”.
    • Use base64url to decode the signature sent by Wix. Let’s call this value “B”.
    • Make sure value “A” = value “B”. If these values don’t match, then don’t display your app – show an error instead.
  • When Wix calls your app settings or dashboard component, check (on the server side) that the value of the permission property in the signed instance is ‘OWNER’. If it isn’t, display a ‘permission denied’ message instead of the app settings or dashboard content.
  • For each save action done in the app settings or dashboard component:
    • Make sure you include the signed-instance parameter in the request.
    • Before you save the changes, validate that this instance exists and that its value is the same as in the original request (when the user first opened the app settings or dashboard component).
    • Check the signDate – if the date of the signature is older than a day, you should display a message saying ‘Please refresh to continue editing your App’.
Support HTTPS

We support HTTPS in the Wix Dashboard, Wix Editor, and live sites, so make sure your app supports HTTPS in all endpoints.

Here are a few pointers to get you started:

  • Install an SSL certificate on your servers. (You can check out Let’s Encrypt, a free and easy to use SSL certificate authority.)
  • Verify that all links in your app use HTTPS – links to pages, images, JavaScript, CSS, etc.
  • Make sure all content in your app supports HTTPS, including third-party content like statistics and CDNs.
Prevent XSS Attacks

Make sure that no one can enter malicious code anywhere in your app.

Check your app’s dashboard, settings panel, and site component for all input fields where users/site visitors can enter text. (For example: comment fields, forms, search fields, title/descriptions fields, etc.)

Keep Data Secure

Encrypt all sensitive data, and don’t store sensitive data in cookies.

Make Payment Settings Private

Do users set up payment info in your app? Since this is sensitive data, show it to site owners only – and hide it from contributors.

We have two types of users in Wix – site owners create the site, and they can invite contributors to edit and manage the website. This means that contributors have access to all apps on the site.

How to implement this:

  1. Check who’s logged in. When Wix calls your endpoint, check the app instance to see if the user ID (uid) is the same as the owner ID (siteOwnerId).
  2. If it’s the site owner, show your endpoint as is. You’ll know it’s the site owner if the uid is the same as the siteOwnerId.
  3. If it’s a contributor, block payment settings. You’ll know it’s a contributor if the uid is different from the siteOwnerId. Here’s what to show in the App Settings panel and Dashboard component.

Ready to test your app? Make sure to check your app as a site owner and as a contributor.

Protect Users’ Data

Once the EU rolls out the new data protection regulation – known as GDPR – users may contact you about accessing, changing, or deleting any personal data your app stores about users or site visitors.

You can handle each request manually as it comes in, or you can develop a faster way to handle these requests automatically.

We suggest learning more about GDPR so that you can understand how it affects your app.

Once your app is live, follow these guidelines if users contact you about their data.
Secure Passwords

Does your app ask users to register/connect an account? Keep users’ passwords secure and confidential, as follows:

  • Use a trusted password hashing function. Passwords must be hashed with a secure hashing function such as SHA-256 or bcrypt. Don’t store raw passwords.
  • Add a long, unique random salt or nonce to each password you store. By making each password unique and long enough, brute-force attacks are less likely to occur (this is when an attacker tries to guess the password or password key).
  • Handle forgotten passwords securely. Here’s how:
    1. Send an email with a reset link so the user can change their password. Don’t send the raw password in an email.
    2. Set reset links to expire within 1-2 hours.
    3. Make sure the endpoint used for reset links is protected from brute-force attacks.

Was this page helpful?

What can we do to improve it?

What did you like about it?