Objective
- At Chargebee, we take data integrity and security very seriously. Due to the nature of the product and service we provide, we are committed to working with individuals to stay updated on the latest security techniques and fix any security weakness in our application or infrastructure reported to us responsibly by external parties.
Eligibility Criteria
To be eligible for a reward:
- Be the first to report the issue to us.
- Subject to the Sections below, the submitted vulnerability must have a demonstrable impact in Chargebee's context. We use CVSS v3 as the vulnerability scoring framework.
- Must contain sufficient information including a proof of concept screenshot, video, or code snippet where needed.
- The person submitting the request must not be an employee, former employee or an immediate relative of an employee or former employee of Chargebee.
- You must comply with the Program terms and conditions.
Scope
The following are in scope for the purposes of this policy and subject to the terms of this policy, are eligible for a reward:
Out of Scope
- Anything not defined in the "Scope" section above.
- Reports from automated tools or scans
Non-Acceptable Category
There are some submissions that we can't accept for rewards. These are typically issues that we already are aware of, or issues that we think demonstrate business value that outweighs the low-level risk, or low-risk issues that are unlikely to result in a code change. Following vulnerability classes are ineligible for rewards:
- Denial of Service
- DMARC/SPF
- Self-XSS
- Malicious File Upload
- Social engineering
- Email Spamming / Spoofing
- Content Spoofing
- Clickjacking and issues that are only exploitable through clickjacking that has minimal impact
- CSRF on forms that are available to anonymous users (e.g. the contact form)
- CSRF with negligible security impact (e.g. adding to favourites)
- Software version number disclosure
- Username or Site Name enumeration
- Unvalidated Open Redirects or Tab Nabbing
- HTML injection
- Username or email address enumeration
- Phishing attack using RTLO, Unicode/Punycode
- Any security weakness or missing best practice without a demonstrable security impact
- Descriptive error messages
- Information disclosure with minimal security impact (e.g. stack traces, path disclosure, directory listings, logs, robots.txt, etc)
- Lack of Secure and HTTPOnly cookie flags
- Weak or missing captcha/captcha bypass
- SSL Attacks such as BEAST, BREACH, Renegotiation attack
- SSL Forward secrecy not enabled
- SSL Insecure cypher suites
- Missing HTTP security headers (including Anti-MIME-Sniffing header X-Content-Type-Options) that do not lead to direct exploitation
- XSS was only possible by an administrator (e.g. administrators can modify HTML templates, that is not an example of an XSS vulnerability)
- Self-XSS that has no security impact (e.g. injecting HTML into your own RTE editor)
- Reports of third-party libraries without an actual proof-of-concept (e.g. if you are aware of a vulnerable library, then you need to submit a proof-of-concept showing that our use of the library is vulnerable)
