Security is a critical part of any web-based business because online apps can be exposed or compromised in many different ways. Before you submit your app, you need to make sure that it's secure so that the merchants who use it won't be at risk.

Security

Your app must not collect Shoplazza user credentials. As explained in Shoplazza API Authentication, public apps must use OAuth.
If your app stores its own credentials, then it must only store salted password hashes instead of actual passwords, as described on the Open Web Application Security Project website.
Your app must be protected against common web security vulnerabilities.
The app must be served over HTTPS using a valid TLS certificate.
Your app must not expose network services unnecessarily.
Your app must not expose its shared secret.
Your app must generate secure tokens, including expirations and search indexing protections, where applicable.
Your app must not process payments or orders outside of Shoplazza's checkout.
Your app must not alter or modify Shoplazza's checkout.

Common web security vulnerabilities

Protecting your app against common web security vulnerabilities

Shoplazza expects that all third-party application be protected against common web security vulnerabilities, including but not limited to, The OWASP Top 10. The OWASP Top 10 is a list of the most critical security risks to web applications and is published by the Open Web Application Security Project (OWASP). The list is a standard awareness document for developers and web application security experts.

If we discover any vulnerabilities in your app during the application review, then your app will be rejected and you'll be required to fix the vulnerabilities before submitting your app for another review.

The OWASP Top Ten list includes all the necessary information to understand common web application vulnerabilities and how to protect against them. The list also includes OWASP cheat sheets and external references. Another resource you can use is the Web Security Academy, a free online training center for web application security. The Web Security Academy includes interactive labs where you can put what you learn to the test.

TLS certificates

Serving your app over HTTPS using a valid TLS certificate

All data exchanged between a client (such as a merchant's web browser) and your app server should be encrypted using Transport Layer Security (TLS) to ensure that any data transmitted can only be read by your application server. TLS certificates are used to protect the end users’ information while it's transmitting and to authenticate the website’s organization identity. Websites secured by a TLS certificate will display HTTPS and the small padlock icon in the browser address bar.

If we can't validate your TLS certificate when we review your app, then your app will be rejected. You'll be required to fix your certificate configuration before submitting your app for another review.

If you don't have a valid TLS certificate already, then you can obtain one free of charge from Let’s Encrypt, a free, automated, and open certificate authority. However, a TLS certificate issued by any trusted Certificate Authority is acceptable. You can't use a self-signed certificate.

After you've created your TLS certificate, you can ensure that it's correctly installed by visiting SSL Checker and entering your app's hostname.

Exposing network services unnecessarily

To help ensure the security of your app, you must not expose any services publicly that aren't necessary for the functionality of your app. Common services that shouldn't be exposed include MySQL, Redis, Memcached, and Elasticsearch. During the app review process, we identify publicly accessible services by using the security tool Nmap to identify open ports.

If our scan detects unexpected open ports when we review your app, then you'll be notified and asked to re-evaluate whether the services need to be publicly accessible. If the services do need to be publicly accessible, then you'll be given a Google form, where you must explain the following:

what services are running on the detected open ports
why each service is necessary to the proper functioning of your application
why the service must be publicly accessible
what steps you have taken to ensure that having the service publicly accessible is safe for Shoplazza merchants and buyers

Security tokens

Generating secure tokens

if your app relies on tokens to authenticate users, then you must ensure the token is randomly generated with 128 bits of entropy to ensure the security of Shoplazza merchant data. In some cases, we allow 64 bits where token length is a concern.

If the token will be publicly accessible (for example, included as a parameter in a URL), then you must ensure that the token has an expiration date of no longer than seven days, and you must prevent the token from being leaked to, or indexed, by third parties.

If we detect the use of tokens in your app without sufficient entropy, or tokens that don't expire or can be leaked or indexed by third parties, then your app will be rejected. You'll be required to fix the identified problem before submitting your app for another review.

The following links can be used to generate secure random tokens for several popular programming languages:

When a token is used to authenticate access to private information, you must ensure that the private information can't be indexed by search engines. Google's guide Block Search indexing with 'noindex' explains how to properly configure a HTML meta tag to prevent search indexing. Additionally, any app URL which accepts a token must ensure it includes a Referrer-Policy header in the HTTP response with a value of origin-when-cross-origin or, preferably, no-referrer.