Security requirements for Zoom Marketplace apps

Zoom follows security best practices and guidelines to evaluate and review the security posture of apps submitted to the Zoom Marketplace. These practices are based on the latest industry security standards, with a focus on the unique needs of Zoom apps and their users.

Optimize app data fetching

Apps should follow optimal patterns for requesting and subscribing to data from Zoom. Avoid using long-polling for the Zoom API; instead, subscribe to Webhook events. This improves performance and simplifies monitoring. You can enable Event Subscriptions for your app in the Features section when creating or managing your app on the App Dashboard.

Optimize app authentication and refresh flows

Apps should avoid making frequent requests for OAuth tokens. Instead, request a token once and store it for future use, rather than generating a new token with each API request.

Cache the data returned by Zoom Authentication endpoints, and reuse access tokens until they expire. Once expired, use a refresh token to request a new access token. For more details on this flow, refer to OAuth 2.0 for User Authorized Apps.

Re-authorization flows

Ensure your app includes a re-authorization flow for users who have removed it and wish to use it again. When they attempt to access a Zoom feature, display an error message prompting them to authorize your app once more before proceeding.

OAuth allow list

In the Add allow lists field, list all unique URLs that Zoom should accept as valid redirect URLs for your OAuth flows. This security measure ensures users are only redirected to the pre-approved endpoints you provide. Include either the complete URL (e.g., https://subdomain.domain.tld/path/to/oauth/callback) or just the base URL (e.g., https://subdomain.domain.tld).

This is a required step to secure your app and protect against unwanted tampering. To minimize the risk of sensitive data leakage, only include URLs that match those in your Redirect URL for OAuth field.

Before submitting your app, ensure that you are following the guidelines regarding your URLs:

  • Use HTTPS for all URLs.
  • Use fully-qualified domain names (FQDN), avoiding localhost addresses.
  • Do not use ngrok domains, unless you can prove ownership.
  • Avoid default Heroku app domains (e.g., app_name.herokuapp.com); instead, use custom domains. If using external domains, provide a justification for adding them to the allow list.

Technical design

The following information pertains to the Technical Design section of the app build flow.

If you answer "Yes" to any questions in the Application Development section, you must provide supporting documentation. This will be treated as confidential and only used for the security review. Generally, submitting supporting evidence is optional, but required in these cases:

  • When requesting to share private apps.
  • When requesting to publish hardware-based apps.
  • If requested by Zoom.

While we don't provide specific templates, you can submit your evidence in any format (screenshots, PDFs, diagrams, etc.).

Examples of evidence to submit include:

  • Feature requirements capture procedures.
  • App testing procedure.
  • Security policies and guidelines for apps.
  • Evidence of Secure Software Development Life Cycle (SSDLC).
  • Proof of secure coding practices (e.g., OWASP standards).
  • Evidence of Static Application Security Testing (SAST) and/or Dynamic Application Security Testing (DAST).
  • Third-party penetration testing.
  • Privacy and security policies.
  • Vulnerability management policies or procedures.
  • Dependency management and patching policies.
  • Incident management procedures.

Follow security best practices

Software Development Lifecycle (SDLC) framework

Adopt a secure SDLC and ensure your coding practices align with industry standards.

Proactive application scanning and penetration scanning

Before deploying new features, perform Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), and Open Source Component Analysis (OSCA) on both source code and the application itself. Regular penetration testing (pen testing) should also be conducted to identify and address vulnerabilities proactively.

Data security (in transit and at rest)

Ensure that data is securely managed to prevent leakage or unauthorized access. This includes encrypting data both in transit (e.g., using TLS 1.2 or higher) and at rest. Regularly rotate encryption keys, secrets, and passwords to maintain security.

Coding to mitigate security vulnerabilities

Developers should write code with security in mind, avoiding common vulnerabilities. This includes implementing input validation, proper authentication, and error handling. Verify user access and permissions before granting access to sensitive information. Apply the Principle of Least Privilege and Role-Based Access Control (RBAC) to restrict access.

Logging and monitoring

Implement logging systems to monitor app usage and data access. Log key events, such as who accessed what data and when. Use Security Information and Event Management (SIEM) systems to detect suspicious activity and quickly address issues.

Patching and updates

Regularly update your backend systems, libraries, and dependencies to address security vulnerabilities before they can be exploited. This includes updating tools, packages, and open-source components, as well as maintaining processes for updating production environments.

Resources