What are we looking for:
When submitting an issue, please provide a technical description that allows us to assess exploitability and impact of the issue.
- Provide steps to reproduce the issue, including any URLs or code involved.
- If you are reporting a cross-site scripting (XSS), your exploit should at least pop up an alert in the browser. It is much better if the XSS exploit shows user's authentication cookie.
- For a cross-site request forgery (CSRF), use a proper CSRF case when a third party causes the logged in victim to perform an action.
- For a SQL injection, we want to see the exploit extracting database data, not just producing an error message.
- HTTP request / response captures or simply packet captures are also very useful to us.
- Please refrain from sending us links to non-Crowdin web sites, or issues in PDF / DOC / EXE files. Image files are OK. Make sure the bug is exploitable by someone other than the user (e.g. "self-XSS").
What we are not looking for:
- Descriptive error messages (e.g. application or server errors).
- HTTP 404 codes/pages or other HTTP non-200 codes/pages.
- Banner disclosure on common/public services.
- Disclosure of known public files or directories, (e.g. robots.txt).
- Clickjacking and issues only exploitable through clickjacking.
- CSRF on forms that are available to anonymous users (e.g. the contact form).
- Logout Cross-Site Request Forgery (logout CSRF).
- Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
- Lack of Secure and HTTPOnly cookie flags.
- Lack of Security Speedbump when leaving the site.
- Weak Captcha / Captcha Bypass.
- Username enumeration via Login Page error message.
- Username enumeration via Forgot Password error message.
- Login or Forgot Password page brute force and account lockout not enforced.
- OPTIONS / TRACE HTTP method enabled.
- SSL Attacks such as BEAST, BREACH, Renegotiation attack.
- SSL Forward secrecy not enabled.
- SSL Insecure cipher suites.
- The Anti-MIME-Sniffing header X-Content-Type-Options.
- Missing HTTP security headers, specifically.
Vulnerability Reporting Agreement
Please review these terms before you test and/or report a vulnerability. Crowdin pledges not to initiate legal action against researchers for penetrating or attempting to penetrate our systems as long as they adhere to this policy.
Crowdin does not permit the following types of security research:
While we encourage you to discover and report to us any vulnerabilities you find in a responsible manner, the following conduct is expressly prohibited:
- Performing actions that may negatively affect Crowdin or its users.
- Accessing, or attempting to access, data or information that does not belong to you.
- Destroying or corrupting, or attempting to destroy or corrupt, data or information that does not belong to you.
- Conducting any kind of physical or electronic attack on Crowdin personnel, property or data centers.
- Social engineering any Crowdin service desk, employee or contractor.
- Conduct vulnerability testing of participating services using anything other than test accounts.
- Violating any laws or breaching any agreements in order to discover vulnerabilities.
The Crowdin security team commitment:
We ask that you do not share or publicize an unresolved vulnerability with/to third parties. If you responsibly submit a vulnerability report, the Crowdin security team and associated development organizations will use reasonable efforts to:
- Respond in a timely manner, acknowledging receipt of your vulnerability report.
- Provide an estimated time frame for addressing the vulnerability report.
- Notify you when the vulnerability has been fixed.
- We are happy to thank every individual researcher who submits a vulnerability report helping us improve our overall security posture at Crowdin.
Please note that by submitting us a vulnerability report, you grant us a perpetual, worldwide, royalty-free, irrevocable and non-exclusive license and right, to use, modify, and incorporate your submission or any parts thereof into our products, services, or test systems without any further obligations or notices to you.
We would be thankful for any further relevant technical information that you may have, especially if reproduction is tricky. If we cannot reproduce it, we cannot reward you. However, there is no need to describe the security impact of your finding - we understand security risks and we can figure that out. We only need technical details.
We maintain flexibility with our reward system, and have no minimum/maximum amount; rewards are based on severity, impact, and report quality. For example, we can provide you with a coupon to get Crowdin Swag. Depending on what you discover, you may go onto the Crowdin Hall of Fame. If you would rather stay behind an alias (handle) or anonymous, we will of course respect that.
We do have specific things we are (and are not) looking for - so check What are we looking for.
If you report several issues that are duplicates in different parts of the service (e.g., the same code running on different nodes or platforms), or part of a larger issue, these may be combined into one and only one reward may be possible.
If someone else has already reported the finding earlier, we will let you know after the issue has been fixed. If several researchers report the same issue, we only reward the sender of the first report that provides us with enough technical details to reproduce the finding. We know that this would give us a loophole to claim that everything's been already previously found, but trust us, we want to be fair.
A reward will not be paid if the finding becomes known by anyone else than you or us, in any way, before it is fixed.
You can always keep tracking of how your issue is progressing. Contact Crowdin Security team for this: firstname.lastname@example.org