Chess.com Bug Bounty Policy

[v0.1.5 | Last updated May 12, 2021] This policy covers all payments to third parties for finding and disclosing bugs, vulnerabilities, and exploits on Chess.com 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 below. The bounty paid will be determined by the severity of the vulnerability. We will agree upon the severity with the Reporter, based on the Common Vulnerability Scoring System, aka “CVSS,” using this calculator: https://www.first.org/cvss/calculator/3.1

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, these Chess.com services and feature are currently not eligible and are considered out of scope:

• Live Chess and its associated protocols
• ChessKid
• Four-Player Chess
• The Events section, and ChessBomb
• Game cheats
• Escalation of your own membership (e.g., obtaining features you did not pay for)

We expect a future Bug Bounty phase in which these are in scope.

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.
• You must work with us to determine the severity of the vulnerability according to CVSS.
• 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:

1. 2022-04-17, v0.1.6: updated table containing payouts, rearranging payouts for different bug classifications
2. 2021-05-12, v0.1.5: updated email address where reports should be sent
3. 2020-07-16, v0.1.4: clarified that proofs of concept must describe steps that a victim would take.
4. 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)
5. 2020-03-20, v0.1.2: temporarily removed CSRF from scope as a "known issue" during a planned security upgrade
6. 2019-07-29, v0.1.1: clarified scope for cheats and obtaining unpaid-for membership features
7. 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.