Required policies

We require that all researchers:

• Do not access customer or employee personal information. If you accidentally access any of these, please stop testing and submit the vulnerability.
• Do not degrade the user experience, disrupting production systems, or destroy data during security testing.
• Use the WhiteHub report submission form to report vulnerability information to us.
• Collect only the necessary information to demonstrate the vulnerability.
• Submit any necessary screenshots, screen captures, network requests, reproduction steps or similar using the WhiteHub submission form (you can use third-party file sharing sites but you have to make sure they are not disclosed to anyone other than us).
• When investigating a vulnerability, please only target your own account and do not attempt to access data from anyone else’s account.
• It is compulsory for you to send all questions and reports to WhiteHub so that we can ensure your benefits and avoid any unnecessary problems. Please do not directly contact the business.
• Public discussion about this program is not permitted
• Your report is not allowed to disclose publicly without our consent. In case of the agreement reached, we can disclose your report on WhiteHub.

Violations will be dealt with by warning, refusing to reward or permanently banning the account on WhiteHub

Qualifying vulnerabilities

Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program. Common examples include:

• Remote Code Execution
• SQL Injection (SQLi)
• Business Logic
• Mobile-specific API vulnerabilities
• Cross Site Scripting (XSS)
• Cross-Site Request Forgery (CSRF)
• Authentication-related issues
• Authorization-related issues
• Data Exposure

Focus areas include:

• Account management (Create / edit / delete an account, login / logout, etc.)
• Data management (Create / edit / delete data or a folder, access control issues)
• Security features for passwords and authentication
• Data storage and autofilling
• Payment service
• New user invitation
• Biometric authentication
• Data export / download / synchronization / sharing
• Emergency / trusted contacts

Non-qualifying vulnerabilities

Depending on their impact, some of the reported issues may not qualify. Although we review them on a case-by-case basis, here are some of the common low-risk issues that typically do not earn a monetary reward:

• Broken client-side access control mechanisms.
• Attacks targeting jailbroken or rooted mobile devices.
• Links that are indexed by Google and/or URL scan sites.
• Two-Factor Authentication (2FA) not being necessary for page load autofill from loading the user’s local offline cache. If the user’s account settings permit offline access for 2FA and if the user has previously logged into the machine, offline mode will override 2FA and allow the web browser to run page load autofill. This will not happen if the login is done on a new device.
• Attacks against endpoints which enable username enumeration or brute forcing of credentials (for example login forms) when those endpoints already have reasonable rate limits in place. Distributed attacks using multiple IP addresses are also excluded.
• WebView-related issues in our in-app browser on Android and iOS. If you find an issue with our implementation/usage and there is a reasonable way to fix it, we may consider it.
• Memory dumps or issues found by tools that read active or cached memory. Performing such an attack would require an already compromised system and a malicious actor with escalated privileges.
• Attacks performed by a malicious application or browser extension installed on the system. On mobile we accept issues exploited by apps with limited privileges (e.g. if an app without any special permission could read the unencrypted passwords, that would typically be in scope).
• Insider threats.
• Denial of service, spam, or phishing attacks.
• Limitations around sharing which are documented on our website.
• Attacks that rely on/have as a prerequisite successfully placing a man in the middle between our servers and the client.
• "Missing" security practices without a realistic attack scenario (e.g. missing HTTP headers, missing certificate pinning) or in general questioning design decisions.