Vulnerability Disclosure Policy

Vulnerability Disclosure Policy

(Updated November 2024)

Codingame intends to keep its service secure and protect its customers’ data. If you’ve found a security issue that you believe we should know about, you can submit it to our team. Eligible findings can receive a reward as stated below.

Eligibility

  • Only the first reporter of a vulnerability can be eligible for reward (based on date of eligible report, very similar vulnerabilities are considered reported yet).
  • You must be available to supply additional information as required, in order for us to fully reproduce and address the issue (please provide PoC, including screenshots or video).
  • Accepted targets are codingame.com, codingame.eu, codingame-app.com and all their existing subdomains.
  • Severity and rewards are decided solely by our team, don’t assess the criticality level, we do, and retain the right to determine if the submitted vulnerability is eligible.
  • Rewards are determined on the basis of the severity level per the below table (note: the table is provided as example of severity, but does not constitute a commitment or contract in any way). Reward amount decisions are final.
  • Analysts not following the below rules will not be eligible for reward.

Rules

  • Spamming the sales or other forms is out of bounds of this program. Abuse will lead to being banned from the program.
  • Do not link main description of the report as attached text or PDF file : we receive many reports and share content via a ticketing tool, having details in PDF / text attachment makes it unworkable and such reports will not be processed. Screenshots, videos and other additional attachments are welcome.
  • Check your findings, disclosing client side javascript code, public API key, or reporting things obviously in the “none” category below is a waste of time for you and us.
  • Avoid privacy violations, destruction or modification of data, and any interruption or degradation of our services.
  • In the case that you acquire private data despite the previous rule, please dispose of it as soon as possible (ie when not required anymore for PoC).
  • Don’t interact with our end-users or their own customers and candidates.
  • No DoS / Bruteforce attacks : use of automated scans or testing is tolerated only if done at the pace of a real human user.
  • No social engineering, nor physical interaction with our users or employees, nor their equipment.
  • Limit the number of accounts you create to the required minimum for the PoC. Creating more than a few accounts will not be tolerated.
  • Allow a reasonable time (up to 90 days) for us to reproduce the issue, and fix it before making any information public. Ask for our approval before making any disclosures.

Security Levels and Examples

Level : None (out of scope / no rewards)

Our basic principle for this program : we consider as a valid vulnerability, only those that can reasonably lead to : data leak, credential leak, undue data modification or deletion, real and reproducible impact on performance / availability. A few low level issues of which impact can be questioned may also be out of scope purposely (due to risk VS benefit considerations)

This list gives examples of vulnerabilities considered out of scope of our disclosure program. These reports won’t be rewarded.

  • Bugs not related to a security issue (non-200 HTTP response codes, 200 response code when an error triggers, application or server errors, and similar), business logic (only) is not considered a security issue (example : sending more tests than expected from the type of customer plan).

  • All RATE LIMITING related reports, or missing throttling as well as theoretical brute-force, except if leading to proven exploitable vulnerability.

  • Issues without a clear security impact (except if obviously leading to a valid vulnerability as stated above) :

    • non-exploitable Self-XSS
    • logged-out CSRF
    • Missing HTTP security headers / cookie flags / CORS / ClickJacking / Mixed content / HSTS SSL/TLS configuration issues
    • Password policy

  • Server-side request forgery (SSRF) not leading to information leak, Cross-site Request Forgery (CSRF) with no or low impact.

  • Verbose messages / files / directory listings not disclosing sensitive information, debug files (except if they can clearly be exploited towards a real security incident)

  • Temporary Debug modes.

  • Origin IP disclosure.

  • Issues affecting third-party services or components not within our control, or with a known vulnerability not yet remediated (except if an applicable fix is publicly available for a reasonable amount of time, and usable in our situation).*

  • 3rd Party tools disputed failures, for instance those that can be balanced by anti-DDOS or WAF (WordPress script loader, wp-cron, login csrf etc…).

  • Server information disclosure (component name / version). Exception can be made if it discloses a server version with an associated patch-able high or critical level vulnerability.

  • Disclosed API keys without proven impact, Public API keys / customer ID for 3rd party tools etc…

  • E-mail configuration (SPF / DKIM / DMARC).

  • DNS configuration : lack of DNSSEC, lack of DNS CAA, DNS records leading to removed or non-existent resources.

  • Open ports without a demonstrated vulnerability.

  • Threats that require privileged access to the target’s devices or stealing credentials, that are outside our control (like access to browser cookies and/or other tokens used to impersonate the user, access to user’s email address, homograph attacks…), and more generally vulnerabilities on which we have no or almost no control.

  • Vulnerabilities only affecting users of outdated or unpatched browsers or software.

  • Systems being phased out except if leading to sensitive information leak

  • Username / email enumeration except if leading to easily exploitable credential leak.

  • Metadata in images.

  • Email validation issues without proven impact.

  • Enabled autocomplete attribute on web forms.

  • Improper cache-control directives.

  • Text injection that is obviously abnormal/fraudulent to user.

  • Manipulation client-side faking vulnerabilities that are not real server-side.

  • Access to underlying OS in test environments (except if able to escape the jailed environment and reach other systems)

  • KNOWN FALSE POSITIVES :

    • env.js site not being a real environment file
    • ClickJacking on pages without user input (ie intentional lack of x-frame headers on non-interactive pages)

  • RISKS ACCEPTED / WON’T FIX

    • Sharing tokens to well-known 3rd parties of trust (Google, Twitter, Facebook etc…)
    • HTML / HyperLink injection on intentionally customizable fields for logged-in or paying users, or sent to internal users.
    • Links / Urls found in Web Archives, including via tools such as wayback, gau etc… (previous issues that leave traces outside of our reach) except if showing a still-existing flaw that we can reasonably fix.
    • CodinGame Community site email lack of validation (on purpose, gives a restricted set of permissions)
    • Open-Redirect to major social networks / video websites.
    • Access to internal registry artifacts purposely shared for use by other domain
    • * Old libraries on Codingame community website related to angularjs (jquery and other libs), except if you can bring a working PoC for at least a HIGH risk.

  • KNOWN ISSUES THAT TAKES TIME TO REMEDIATE AND ARE REPORTED YET

    • Missing CSP Header
    • Remaining non-PII user resources after account deletion.

Level : Low

  • Open redirections (with proven impact).
  • Obvious Server misconfiguration leading to low severity risk.
  • Broken e-mail validation (with proven impact)
  • Reflected XSS.
  • Non-public Information leaks or disclosure (excluding sensitive user data).
  • Other low-severity issues (Limited risk or overly hard to exploit).

Level : Medium

  • CSRF / XSRF.
  • SSRF to an internal service.
  • Stored XSS.
  • Credential stealing requiring plausible user interaction.
  • Other medium-severity issues (Medium risk or hard to exploit).

Level : High

  • Privilege escalation.
  • Non-public Information leaks or disclosure including sensitive user data (not requiring user interaction).
  • Other high-severity issues (High risk or reasonably easy to exploit).

Level : Critical

  • SQL injection.
  • Remote code execution.
  • Server access (full command set).
  • Broken authentication (ie no password required or any password accepted)
  • Other critical-severity issues (Critical risk or very easy to exploit / amplify).

Rewards

Rewards are paid by severity tier as per below table.

Currency conversion or other transaction fees can’t be added to the reward amount.

None0 USD
Low50 USD
Medium100 USD
High250 USD
Critical500 USD

Rewards up to and including 100 USD value will be paid only via a voucher usable on 300+ services. Options include virtual debit card (Visa), virtual gift cards, and more. We do not provide rewards at this level via Paypal. More details HERE.

Higher tier rewards (250-500 USD) can be paid by the options above, or via Paypal. To receive a reward via Paypal you must issue to us a proper proforma invoice, stating your legal business/personal contact and VAT details.

“Hall of Fame”

  • Milan jain (scriptkiddie)
  • Suprit Pandurangi
  • Love Yadav
  • Rutuparn Satpute
  • Sachin Kalkumbe
  • Hamdan Ali Siddiqui
  • Ranjeet Singh (geekboyranjeet)
  • Richa Behl
  • Gokul AP
  • Opinder Singh
  • Girish B O
  • Gnana Aravind 
  • Moncef Djouadi (sheerwood)
  • Yassine Tamani