Security is a critical part of any web-based business because online apps can be exposed or compromised in many different ways. Ensure your app is secure before submission to protect merchants from potential risks.

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 your TLS certificate cannot be validated during the review process, your app will be rejected until the issue is resolved.

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.

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

Exposing Network Services Unnecessarily

To ensure the security of your app, avoid exposing any services publicly unless they are essential for its functionality. 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 during the review, you will be notified and required to re-evaluate whether the services must remain publicly accessible. If the services need to remain accessible, you will be provided with a Google form to 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 security measures have been implemented to ensure the service is safe for Shoplazza merchants and buyers

Security Tokens

Generating secure tokens

If your app relies on tokens to authenticate users, the tokens must be randomly generated with at least 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.

For tokens that will be publicly accessible (e.g., included as parameters in a URL), ensure they meet the following requirements:

Have an expiration date of no more than seven days.
Are protected from being leaked or indexed by third parties.

If tokens in your app lack sufficient entropy, do not expire, or are susceptible to leakage or indexing by third parties, your app will be rejected during the review process. Identified issues must be resolved before resubmission.

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.