Security

Zoom takes the security of user data and its systems very seriously. All applications submitted to be published on the Marketplace undergo a multi-step security test intended to maintain customer security and resilience of the ecosystem as a whole. For more information, reference the Security Testing procedures within the Marketplace Submission Review.

For specific recommendations on best security practices for Marketplace apps, reference the sections below.

Transport Layer Security (TLS)

All client applications and web browsers transferring user content must do so over end-to-end encryption using TLS at every point of transfer. TLS protections enable browsers to transfer data through HTTPS (Hypertext Transfer Protocol Secure), which enables authentication of the requested data.

Websites should only support TLS 1.2 or higher, with all other protocols disabled. Although versions lower than TLS 1.2 are considered highly insecure, we may consider your case if you support lower versions for business reasons.

All connections and endpoints made available by your application to Zoom are required to transfer through TLS protection. Test out your TLS security at https://www.ssllabs.com/ssltest/.

Secure storage of data

All apps developed on the Marketplace are given unique credentials which enable them to securely access account data and make changes on behalf of itself and users who have installed the app.

  • API credentials, SDK keys, and Client secrets must never be exposed in client-side apps, local storage, or in a public repository.

  • The following fields should never be logged or stored in cleartext, and should be encrypted at all times when at rest:

    • OAuth & Security Tokens
    • Access Keys & Secrets
    • Passwords
    • File contents
    • User Personally Identifiable Information (PII)

Exposing account credentials causes a serious vulnerability to your Zoom account, an entire application, and all of an app’s users. If necessary, app credentials can be regenerated from the Marketplace Dashboard of each app.

Sensitive data exposure

  • Sensitive data exposure via URLs - Ensure that sensitive data is never sent to the server in URL parameters of requests. Sensitive information within URLs may be logged in various locations, like the user’s browser or server. URLs could also be displayed in history, bookmarked or emailed around by users. They may also be disclosed to third parties via the Referer header.

  • Sensitive data exposure via HTTP - Please review and audit responses to HTTP requests for sensitive information like Zoom OAuth and refresh tokens.

Data compliance with Zoom

All Marketplace app developers must comply with users’ preferences on how their data should be handled. You must monitor your app’s deauthorization event webhook which is sent to the app’s De-authorization Endpoint URL shortly after a user uninstalls your app.

This is a mandatory requirement and can block your app from being approved. Learn more here.

Verifying requests from Zoom

It is highly recommended that all apps receiving event data from Zoom through Webhooks verify that the incoming request is coming from Zoom. Without doing so, event notification endpoint URLs could be vulnerable to fraudulent requests and denial of service attacks.

Event notification endpoint URLs are the endpoints of your application which are set to receive notification data from Webhook events. When a subscribed event occurs, Webhooks send an HTTP POST request containing a verification token along with the payload data for the event.

To secure an event notification endpoint URL, verify that the value contained in the authorization field in the incoming request matches the verification token created when event subscriptions are successfully added to your app. To find an app’s verification token, navigate to the Feature section in your app’s dashboard on Zoom App Marketplace.

Additional security practices

Cookie attributes

Ensure that sensitive cookies are marked with secure and httpOnly flags.

  • secure: This attribute ensures the cookie is to be sent only through an encrypted channel.
  • httpOnly: This attribute is used to help prevent attacks such as cross-site scripting, since it does not allow the cookie to be accessed via a client side. script such as JavaScript. This attribute also informs the browsers that the cookie cannot be accessed via the DOM document.cookie object.

Avoid clickjacking vulnerability

Implement the use of Content Security Policy or X-Frame-Options headers where necessary to ensure the app is not vulnerable to clickjacking attacks. While framing is a feature, it can also pose as a security threat without insufficient measures in place. Please ensure that this feature is securely implemented. Learn more by from OWASP’s best practices.

Logging and error handling

Logging information for app debugging and diagnostics is an important function to understand app and system performance as well as to identify vulnerabilities and malicious intent. Security-focused logging should be used to identify any potential attacks and enable responses to secure or invalidate a user session or token. If submitted data or suspicious user activity is detected, encoded information on the session should be sent to a secure logging service. Do not ever log sensitive information.

Errors reported during app usage are commonly used to report information directly to a user, but this provides the risk that data provided to the user within a client could also provide information useful to an attacker. For example, it is possible that information within the error response could be used to determine sensitive information and the existence of user accounts.

Information leakage is a common vulnerability that exposes data through error codes shown to users which include common debugging information, stack traces, or failed database queries. Application errors should be logged for debugging and reporting purposes but should not be exposed within a client. For a review of preventing information leakage, reference the OWASP’s document on Error Handling.

Cross-site Request Forgery

Cross-site Request Forgery (CSRF) is a common vulnerability which allows a malicious program to cause unauthorized actions on a site when a user is authenticated. In a CSRF attack, a browser request takes advantage of the authenticated access of the user, allowing an attacker to compromise end user data and operations without their knowledge.

Many common web frameworks have CSRF support built in but unique vulnerabilities are exposed based on specific app capabilities. For a comprehensive view on implementing CSRF defense, reference the OWASP guide to CSRF Prevention.

Suggested external resources

For a wide range of topics on web and app security best practices, The Zoom Marketplace highly recommends reviewing the OWASP (Open Web Application Security Project), a worldwide not-for-profit organization focused on improving the security of software. Reference the OWASP Top 10, which provides a good starting point for security issues and vulnerabilities.

  1. Open Web Application Security Project (OWASP)
  2. OWASP Top 10
  3. General Data Protection Regulation (GDPR) Compliance Guide
  4. PCI Security Standards Council