Chess.com Bug Bounty Policy
[v0.1.5 | Last updated May 14, 2024] This policy covers all payments to third parties for finding and disclosing bugs, vulnerabilities, and exploits within the Chess.com domain and not on other domains and related products. This policy is only guidance for you and Chess.com, and does not represent a contract, promise, or obligation on either party.
Bugs and Vulnerabilities
Bugs are any feature or function of the site, mobile apps, or API which are not operating as intended. The result may be annoying, misleading, inaccurate, missing, or simply non-functional.
Vulnerabilities are bugs which damage data or expose non-public data about individual members or the company itself, or which allow a person who is not the owner of an account to act as the owner. Vulnerabilities may be minor to severe, and in some cases may require Chess.com to follow formal legal processes. This document helps you, the reporter of a bug, follow guidelines that let us respond properly. We will refer to you as "Reporter" for the rest of this document.
We do not pay a bug bounty for user interface, graphics, or data bugs which do not pose a security threat. However, reporting these bugs through our “Report a Bug” system in the Help menu allows us to regularly award free memberships to Reporters who help us the most.
We pay a bounty for vulnerabilities disclosed according to the procedure described in this policy.
- The bounty paid will be determined by the severity and likelihood of an attack.
- This typically has to do with the amount of traffic to the specific endpoint of the vulnerability.
- If there is a vulnerability which you have found that does not look to be included in the list below but believe it should be, please reach out and we can discuss the details further.
- In order to qualify for a bounty, the reported vulnerability must be new and unique, if another user has submitted the same bug in the past, it will be marked as duplicate and not be eligible for a bounty.
- Thoroughness and clarity of the submitted vulnerability report are also factors in determining the bounty within the value range.
- Please refer to the section below titled CLAIMING A BOUNTY, for more info about reporting format
- We will agree upon the severity with the reporter, based on the table provided below.
| VULNERABILITY TYPE | DETAILS | BOUNTY |
|---|---|---|
| Remote code execution | Any successful proof of code execution on server side including but not limited to: - File Inclusion leading to potential binary or malware execution - SQLi - server-side script execution - Reverse shell on server |
$1000-4000 |
| Mass user account data leakage | Obtain many users’ private account data and/or passwords with a single exploit | $800-3000 |
| Broken Authentication and Session Management | - Any form of Authentication Bypass - Session Fixation, resulting in gaining access to any/multiple user’s accounts - 2FA bypass - Account takeover - Obtain a target user password |
$600-800 |
| Server side injection | This category covers any injection that leads to server side actions such as: - Template injection - Response splitting CRLF. (Must show impact) - SSRF with payload showing impact |
up to $400 |
| CSRF | - Damage user settings - Perform actions on behalf of other users (*Excluding actions performed as a result of XSS) |
up to $400 |
| Application logic bypass | This category covers all vulnerabilities dealing with: - Bugs in application logic/flow that can result in a security issue - Broken Access Control (BAC) - Insecure direct object references (IDOR) |
up to $400 |
| XSS |
**Payouts will be for discovering a new initial vector. No need to provide a full fledged proof of concept on the payload for the XSS. A simple alert() will suffice. |
up to $250 |
| Content Spoofing | HTML injection leading to believable phishing | up to $250 |
| Pii Leakage | - Obtaining users Pii including: - IP address - User Geolocation - Email Address - Telephone number |
up to $200 |
| Server Security Misconfiguration | Captcha Bypass | up to $150 |
| Server Security Misconfiguration | No Rate Limiting on Critical Forms | up to $100 |
| Non-sensitive information leakage | Ex. Login form providing different responses when a username is incorrect vs a password being incorrect, allowing easier brute force ability | up to $100 |
Limitations
By offering a Bug Bounty, we are asking for helpful advice. You may not attack or cause damage to the site, the users’ data, or the company’s reputation. All efforts must be polite and cause no harm. You must take all reasonable actions to confine the effects of your work to test accounts created specifically for this purpose and avoid experiments visible to the public or during live events. Any unannounced vulnerability investigation indistinguishable from an attack and/or violating the terms of this program will be treated as an attack, and we may involve law enforcement agencies to investigate and prosecute. If you believe your exploit may cause harm, contact us before you attempt it, and we will work with you to devise a safe mechanism for demonstration.
Chess.com will attempt to respond and work with you within 5 business days. Failure to do so does not invalidate your claim; we will get back to you as soon as we can.
Reports from automated tools, exploits on unsupported browsers or old mobile apps, physical-access or social-engineering attacks (including phishing or impersonating staff), denial of service, email, issues relating to systems out of Chess.com’s control, and issues that we are already aware of are not eligible. Deviations from industry standard procedures and settings are not eligible for a bug bounty without a demonstration that the effect can be exploited in specific harmful ways.
During this phase of the bug bounty program, only security issues within the Chess.com domain will be eligible and in scope for bug bounty.
In case we decide to extend the Bug Bounty program to other domains like Chesskid, Chessable or others, we will update this article and make that clear.
Claiming a Bounty
To claim a bounty for a vulnerability you have discovered, follow these steps:
- Report your finding to bounties{at}chesscom{dot}atlassian{dot}net.
- You must report your finding to us first and exclusively. Any disclosure to the public prior to a released fix, disclosed by you or anyone, invalidates all claims to a bounty. Any attempt to exploit a found vulnerability beyond what is necessary to demonstrate and report it will be considered an attack and invalidates the claim to a bounty.
- Your report must include a proof of concept, working code, steps to replicate, or other documentation so that our technical teams can identify which systems are affected and how. A video or other demonstration is insufficient by itself. The proof of concept must execute in the same manner that a victim may realistically execute it; specifically, sending code to us to download and execute locally is unrealistic, and so you must host such a proof on a website that you control and then send us the link. If the severity of the vulnerability is based on automation, you must submit proof that it can be automated. If we cannot replicate the bug with your steps, you must work with us to understand why, and you may be asked to provide further proof of the vulnerability.
- You must provide your real name and contact information for payment. We will not submit payment to anonymous or unverified accounts. We may ask for reasonable ID verification; a documented and valuable online reputation may be sufficient.
- Only the first to submit a complete report on a given vulnerability will receive a bounty. Subsequent, helpful reports received before a patch is available may receive a bounty at our discretion. Separate exploits of the same bug may be considered the same vulnerability at our discretion. “First to submit” is based on the receipt timestamp of the email received at the address above, containing the demonstration or documentation and real-person contact information. Incomplete submissions are considered submitted only when completed.
- Payment will be made after the vulnerability is fixed and verified by our teams, the submitted proof of concept, and the Reporter. In some cases, we may ask that you not disclose any information about this vulnerability an agreed-on amount of time; if we do, then we will ask this when we confirm your submission, and an additional bounty will be paid to compensate for your inability to use this discovery for promotional or instructional means.
- Regressions of previously fixed vulnerabilities will be paid at half price.
If you have any questions or concerns, you may reach out to the email address above. Thank you!
Edits:
- 2023-08-30, v0.1.7: Updated the payouts table and out of scope items to reflect more accurately what we are looking for from researchers and removing CVSS as it does not accurately reflect our assessment of risk
- 2022-04-17, v0.1.6: updated table containing payouts, rearranging payouts for different bug classifications
- 2021-05-12, v0.1.5: updated email address where reports should be sent
- 2020-07-16, v0.1.4: clarified that proofs of concept must describe steps that a victim would take.
- 2020-07-03, v0.1.3: reinstated CSRF to scope; explicitly identify ChessKid, phishing as out-of-scope; reduced payout schedule and added lowest tier; clarified policy semver (below)
- 2020-03-20, v0.1.2: temporarily removed CSRF from scope as a "known issue" during a planned security upgrade
- 2019-07-29, v0.1.1: clarified scope for cheats and obtaining unpaid-for membership features
- 2019-07-25, v0.1: initial draft
Policy semver: patch numbers will be incremented when we edit for clarity; minor versions are incremented when we add or remove significant items; v1.0.0 will be declared when all major systems are in scope and the policy is stable for 6 months.
