# 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](/docs/distribute/security-best-practices/) procedures within the Marketplace Submission Review. For specific recommendations on best security practices for Marketplace apps, reference the sections below. ## Vulnerable libraries Modern web applications often incorporate open-source components such as libraries and frameworks. All client applications and web browsers must have updated components. Any component with a known vulnerability becomes a weak link that can impact the security of the entire application. We may consider cases where components cannot be updated for business reasons. For more information on preventing components from becoming vulnerable and outdated, see [OWASP Vulnerable and Outdated Components Best Practices](https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/). ## 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 transfer point. 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 highly insecure, we may evaluate your case if you have valid business reasons for supporting. 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 - Personally Identifiable Information (PII) Exposing account credentials causes a critical vulnerability to your Zoom account, the entire app, and all of its 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, such as 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. ## Security misconfiguration Application Security Misconfiguration attacks exploit configuration weaknesses found in web applications. Security misconfigurations can happen at any level of an application stack, including the platform, web server, application server, database, framework, and custom code. Application-based configuration files that are not properly locked down may reveal clear text connection strings to the database; and default settings in configuration files may not have been set with security in mind. All of these misconfigurations may lead to unauthorized access to sensitive information. For more information on how to prevent the likelihood of Security Misconfigurations, see [OWASP Security Misconfiguration Best Practices](https://owasp.org/Top10/A05_2021-Security_Misconfiguration/). ## 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. For more information, see [OWASP best practices](https://cheatsheetseries.owasp.org/cheatsheets/Clickjacking_Defense_Cheat_Sheet.html). ### 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](https://owasp.org/www-community/Improper_Error_Handling) 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](https://owasp.org/www-project-proactive-controls/v3/en/c10-errors-exceptions). ### Cross-site Request Forgery (CSRF) [Cross-site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/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](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html). ### Cross-Site Scripting (XSS) XSS attacks inject malicious scripts into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser-side script, to a different end user. For more information on how to prevent Cross-Site Scripting attacks, see [OWASP XSS Best Practices](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html). ### 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)](https://www.owasp.org), a worldwide not-for-profit organization focused on improving the security of software. Reference the [OWASP Top 10](https://www.owasp.org/index.php/Top_10-2017_Top_10), which provides a good starting point for security issues and vulnerabilities. - [Open Web Application Security Project (OWASP)](https://www.owasp.org) - [OWASP Top 10](https://owasp.org/www-project-top-ten/) - [General Data Protection Regulation (GDPR) Compliance Guide](https://gdpr.eu/) - [PCI Security Standards Council](https://www.pcisecuritystandards.org/) - [OWASP Mobile Top 10](https://owasp.org/www-project-mobile-top-10/) - [OWASP Mobile Application Security](https://owasp.org/www-project-mobile-app-security/)