Security Guidelines

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.

Security controls

Zoom apps operate on user-controlled devices. We recommend implementing security controls as you would for web browsers. Rely on verified data sources such as x-zoom-app-context or trusted service-to-service mechanisms, including web APIs and webhooks.

For additional information, see the listed resources.

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, keys, and 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.

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.

The verification token will be deprecated in June 2025. We recommend replacing the verification token with the secret token to verify Zoom event notifications. See Using Webhooks: Verify that events are sent by Zoom for details.

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.

Cookie scopes

Cookies used by a Zoom Apps app are limited in scope to meeting and panel. Any cookie set in one scope will not work in another scope. This means that a user may have to log in to the app in each context independently.

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.

See also OWASP Secure Headers for App Home URL and HTML.