Zoom takes the security of user data and its systems very seriously. All applications submitted to be published 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 security best practices for Marketplace apps, reference the sections below.
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 for users.
All API credentials, SDK keys, and Client Secrets should be stored securely and must never be exposed in client-side apps or in a public repository.
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 in the Manage dashboard of each app.
Cleartext is data stored and transmitted without cryptographic protection, and thus deemed to be stored insecurely. Data sent over HTTP is sent as cleartext.
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
- File contents
- User Personally Identifiable Information (PII)
Any information about a user or content created by a user should be stored in an encrypted or hashed format.
For instances where sensitive data must be stored, it must then be protected cryptographically to prevent unauthorized access.
Sensitive user data, stored only if required for the business function of an application, should always be handled with strict caution and in active compliance with privacy laws such as the General Data Protection Regulation (GDPR) and financial data protection standards such as the Payment Card Industry Security Standard (PCI DSS). Passwords, financial and payments data, and any personally identifiable information (PII)
Connections to databases where user content is provided within a query must be protected to prevent exploitation and unauthorized access. Relational (SQL) and NoSQL databases should consider vulnerabilities to queries, configuration, authentication, and communication. Any point of access to a database should be securely authenticated, including connections to external services and APIs.
The most common and fundamental vulnerability to databases is through SQL Injection. SQL Injection presents vulnerabilities to an entire application including both to user data it contains and the database hosting provider. To prevent SQL Injection, any database receiving data should prevent against SQL syntax that may be contained in untrusted user inputs. The best way to prevent this is through Query Parameterization which is a strategy to interpret user input as a parameter value, thus limiting the input from executing as SQL syntax.
SSL/TLS & Transport Layer Protection
All applications transferring user content must do so over end-to-end encryption using SSL/TLS at every point of transfer. SSL (Secure Sockets Layer) and the more secure and updated protocol Transport Layer Security (TLS) are methods of encrypting data transmitted between two connections to protect it from modification. Any client application, web browser or otherwise, transferring or receiving data from a web server should always do so over SSL/TLS.
SSL/TLS protections enable browsers to secure data through HTTPS (HyperText Transfer Protocol Secure), which enables authentication of the requested data. All connections and endpoints made available by your application to Zoom are required to serve data HTTPS through SSL/TLS protection.
Before performing any type of action against data submitted by a user, you must first ensure the user is properly authorized to perform the operation. To do so, perform programmatic checks on the data as soon as it is received. For example, inputs like form fields should check for data type, minimum and maximum values, or specific acceptable values before receiving submissions.
Client-side validations can commonly be bypassed by attackers, so any input validation performed client-side should also be performed server-side before the data is accepted. Input validation is not a fail-safe method of protecting against attacks like SQL Injection or Cross-Site Scripting and should be used alongside multiple protection strategies.
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.
Event Notification Endpoint URLs
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.
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.
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 Manage page.
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.