Bug Bounty

Overview

RapidSwap's Bug Bounty program is a cybersecurity initiative aimed at involving independent security researchers to identify and exploit vulnerabilities within the company's systems and applications. Participants receive financial rewards for each identified and documented vulnerability, with the reward amount varying based on the risk level and complexity of exploiting the vulnerability. By taking part in this program, you consent to the terms and conditions outlined below.

Where can one find exploits for vulnerabilities?

Domain:

rapidswap.org

Telegram channel:

@rapidswap_support

Rewards for vulnerabilities

The reward is paid in USDT or equivalent in another cryptocurrency (BTC, ETH, LTC, XMR).

  • Critical: 400 - 1000 USDT
  • High: 200 - 400 USDT
  • Medium: 100 - 200 USDT
  • Low: 50 - 100 USDT
  • Absent/Missing: 0 USDT

Vulnerabilities that we do NOT accept

  • Findings from vulnerability scanners and various automated tools
  • Revealing non-confidential information, such as the product version.
  • Releasing publicly accessible user details, such as a nickname.
  • Reports concerning product or protocol versions that do not provide evidence of an actual vulnerability.
  • Reports on absent protection mechanisms or best practices (such as lacking CSRF markers and safeguards against framing or clickjacking) fail to show any real impact on user or system security.
  • Documentation of both published and unpublished DNS records for SPF, DKIM, and DMARC.
  • Cross-site request forgery resulting in a logout (logout CSRF)
  • Vulnerabilities in partner products or services
  • Security of devices that are rooted, jailbroken, or otherwise modified, along with the applications on them.
  • The capability to reverse engineer an app or insufficient safeguards against this vulnerability.
  • Open redirections will only be permitted if a security risk is identified, such as the potential theft of an authorization token.
  • Entering unformatted text, sound, images, or videos into a server response beyond the user interface (such as in JSON data or an error message) is permissible as long as it does not lead to UI spoofing, alter UI behavior, or produce other adverse effects.
  • Same Site scripting, download and similar attacks
  • CSP-related reporting for domains lacking a Content Security Policy and those with insecure eval/inline directives in their domain policies.C
  • IDN Homography attacks
  • Cross Site Port Attack (XSPA) (scanning IP/ports to external networks)
  • Excel CSV formula injection
  • Self-XSS without demonstrating impact
  • Attacks that necessitate complete access to either a local account or a browser profile.
  • Scenario attacks that depend on an unproven vulnerability in a third-party site or app as a prerequisite.
  • Theoretical attacks without proof of exploitability
  • Denial of Service (DoS) vulnerabilities associated with submitting excessive requests or data.
  • Disclosure of unused or properly restricted JS API keys (e.g. an API key for an external mapping service)
  • Capability to execute an action not accessible via the user interface, without presenting any identified security risks.
  • Missing best practices in SSL/TLS configuration
  • Missing HTTP headers and Cookie flags

Limitations in vulnerability testing

  • When testing RCE, SQLi, LFR, SSTI it's allowed to use only the MINIMAL possible Proof of concept (PoC) for proof (sleep, reading /etc/passwd, curl)
  • Accessing user accounts, data, or any other confidential information beyond the essential actions required to demonstrate the identified vulnerability is prohibited.
  • Execute attacks on RapidSwap systems by employing social engineering tactics such as phishing and vishing, along with sending spam emails to clients, partners, and employees.

Report design requirements

The vulnerability report will include the following sections:

  • Name of the vulnerability
  • Name and version of the impacted software component.
  • Comprehensive overview of the identified vulnerability along with instructions for reproducing it (featuring video and/or screenshots).
  • Overview of the attack scenario: who can leverage the vulnerability, the intended purpose, the method of exploitation, and other relevant details.
  • Recommendations on how to fix the vulnerability

Vulnerability report review rules

  • We will get back to you within 5 business days.
  • We handle reports within 10 business days of receiving our response.
  • We may need to extend the time required to process reports; if that happens, we will notify you of the delay.
  • We will assess the reward amount within 15 business days after processing.
  • We retain the authority to update the final threat level associated with the identified vulnerability.

Submit your vulnerability reports to [email protected] .