Política de recompensa de bug

This Policy

The safety of our users’ funds and personal data is our main priority, therefore, the security of our platform and services is the field we work on daily and implement a number of advanced security technologies. Nevertheless, the contribution of the security researchers, who assist us in keeping our products and users safe, is extremely important for us, that is why we launched a vulnerability detection bounty program. The terms and conditions of our bug bounty program are described in this Bug Bounty Policy.


Resources available for vulnerabilities detection:
internal.whitebit.com - https://whitebit-exchange.github.io/api-docs/
Android App - https://play.google.com/store/apps/details?id=com.whitebit.android
iOS App - https://apps.apple.com/ua/app/whitebit/id1463405025


Vulnerabilities found in out of scope resources are unlikely to be rewarded unless they present a serious business risk (at our sole discretion). In general, the following vulnerabilities do not correspond to the severity threshold:


  • Vulnerabilities in third-party applications
  • Spam (SMS, email, etc)
  • Best practices concerns without real security impact
  • Recently (less than 30 days) disclosed vulnerabilities
  • Vulnerabilities affecting users of outdated browsers or platforms
  • Social engineering, phishing, physical, or other fraud activities
  • Publicly accessible login panels without proof of exploitation
  • Reports that state that software is out of date/vulnerable without a proof of concept
  • Vulnerabilities involving active content such as web browser add-ons
  • Most brute-forcing issues without clear impact
  • Theoretical issues
  • Missing HTTP security headers without real security impact
  • TLS/SSL сertificates related issues
  • DNS issues (i.e. MX records, SPF records, etc.)
  • Server configuration issues (i.e., open ports, TLS, etc.)
  • Open redirects
  • Session fixation
  • User account enumeration
  • Clickjacking/Tapjacking and issues only exploitable through clickjacking/tap jacking
  • Descriptive error messages (e.g. Stack Traces, application or server errors)
  • Self-XSS that cannot be used to exploit other users
  • Login & Logout CSRF
  • Weak Captcha/Captcha Bypass without clear impact
  • Lack of Secure and HTTPOnly cookie flags
  • Username/email enumeration via Login/Forgot Password Page error messages
  • CSRF in forms that are available to anonymous users (e.g. the contact form)
  • OPTIONS/TRACE HTTP method enabled
  • Host header issues without proof-of-concept demonstrating the vulnerability
  • Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
  • Content Spoofing without embedded links/HTML
  • Reflected File Download (RFD) without clear impact
  • Mixed HTTP Content
  • HTTPS Mixed Content Scripts
  • DoS/DDoS issues
  • Manipulation with Password Reset Token
  • MitM and local attacks
  • Vulnerabilities already known to us, or already reported by someone else (reward goes to first reporter)
  • Issues without any security impact


  • Attacks requiring physical access to a user's device
  • Vulnerabilities requiring extensive user interaction
  • Exposure of non-sensitive data on the device
  • Reports from static analysis of the binary without PoC that impacts business logic
  • Lack of obfuscation/binary protection/root (jailbreak) detection
  • Bypass certificate pinning on rooted devices
  • Lack of Exploit mitigations i.e., PIE, ARC, or Stack Canaries
  • Sensitive data in URLs/request bodies when protected by TLS
  • OAuth & app secret hard-coded/recoverable in IPA, APK
  • Sensitive information retained as plaintext in the device’s memory
  • Crashes due to malformed URL Schemes or Intents sent to exported Activity/Service/Broadcast Receiver (exploiting these for sensitive data leakage is commonly in scope)
  • Any kind of sensitive data stored in app private directory
  • Runtime hacking exploits using tools like but not limited to Frida/Appmon (exploits only possible in a jailbroken environment)
  • Any URIs leaked because a malicious app has permission to view URIs opened
  • Exposure of API keys with no security impact (Google Maps API keys etc.)


There is no limit on the maximum and minimum reward size, we reserve the right to increase or decrease the size of the reward depending on the seriousness of the vulnerability found. Researchers are more likely to receive increased rewards if they can demonstrate how the found vulnerability may be used to cause the most harm.

The table below shows an approximate reward for detecting vulnerabilities:

Vulnerability Severity Reward
Remote code execution Critical $10,000
Manipulating user balances High $10,000
XSS/CSRF/Clickjacking affecting user balances/trading/exchange/deposits Medium $2,000
Theft of information related to passwords/API keys/personal information Medium $2,000
Partial authentication bypass Medium $1,500
Other vulnerability with clear potential for financial or data loss Low $500
Other CSRF (excluding logout CSRF) Low $500

Rules and Guidelines to Report the Vulnerabilities and Get the Reward

Taking into account the illegal nature of unauthorized access to the computer systems, we agree not to take legal action against the researchers nor ask law enforcement bodies to investigate the cases of the security breach by the researchers in case they comply with the industry standards and responsible disclosure guidelines described in this section.

  1. Main points to receive a reward for detecting vulnerabilities:
  • immediately submit a report to security@whitebit.com

  • provide us with enough time to fix the vulnerability/weakness/issue before any information regarding it will become in any manner publicly announced

  • NOT cause any damage to WhiteBIT infrastructure and its users

  • NOT mislead users or employees of WhiteBIT while detecting vulnerabilities

  1. You must be the first to report a vulnerability to receive a reward.

  2. In case you find chain vulnerabilities we pay only for vulnerability with the highest severity.

  3. You should send a clear textual description of the work done, along with steps to reproduce the vulnerability.

  4. Responsible disclosure guidelines:

  • Provide details of the vulnerability, including information needed to reproduce and validate the vulnerability.

  • Make a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our services.

  • Do not modify or access data that does not belong to you.

  • Report the vulnerability as soon as possible.

  • Do not use the detected vulnerabilities for unjust enrichment. If you use the vulnerability in such a way that can cause harm to WhiteBIT, our users and third parties and do not report to WhiteBIT about the vulnerability, you will not receive a reward and we reserve the right to commence legal action against you.

  • Do not violate any law and stay in the defined scope, and do not participate in any illegal actions (activities).

  • If you encounter personally identifiable information or other sensitive data for accounts or data breach by other persons, please stop accessing that data immediately, and report the issue to WhiteBIT by the e-mail addresses legal@whitebit.com and dpo@whitebit.com. Do not store or transmit other users’ data, and please destroy all copies of data that is not yours that you accidentally or deliberately captured during the course of your research.

  • After sending a report, you cannot tell anyone or anywhere about the vulnerability. Public disclosure of a vulnerability makes it ineligible for a reward. Furthermore, you shall not store screenshots and/or executable codes and scripts related to the vulnerability not to make the information available to third parties.

Non-security Issues

You may let us know about non-security issues at support@whitebit.com