Better is committed to working with and rewarding the efforts of the global security community. Our bounty program aims to reward those who make valuable contributions to the security of our platform with bounty payments of up to $20,000 for critical vulnerabilities. Good luck and happy hunting!
Program Terms & Eligibility
In order to participate in the program, you must:
- Not be a resident of, or make a submission from, a country against which the United States has issued export sanctions or other trade restrictions (e.g., Cuba, Iran, North Korea, Sudan and Syria);
- Your participation in the Program will not violate any law applicable to you, or disrupt or compromise any data that is not your own.
- Not be employed by Better or its subsidiaries.
- Not be an immediate family member of a person employed by Better or its subsidiaries.
- Better reserves the right to terminate this Program at its discretion.
Bounty Reward Eligibility
To be eligible to receive a bounty reward, you must:
- be the first person to submit a site or product vulnerability,
- submit a in-scope vulnerability based on the requirements listed on this page,
- submit a vulnerability that is deemed valid by our security team,
- have complied with all terms of this program.
All submissions reports must include:
- a description of the vulnerability being reported
- a description of exploitability and impact
- step-by-step instructions on how to reproduce the vulnerability (ideally with screenshots or video)
- supporting evidence (e.g. screenshots, videos, exploit code, Burp requests/responses, etc.)
Rules of Engagement
To avoid being blocked by rate limiting controls, keep the HTTP request volume below 300 requests per minute per IP address. Depending on which rules are triggered, the block may be permanent and will require an email to the Better security team to request manual removal from the deny list.
- To further avoid potential blocks, it is recommended you include
User-Agentvalue in your request headers.
When researching security issues, especially those which may compromise the privacy of others, you must use only test accounts in order to respect the privacy of Better users. Accessing private information of other users, or performing actions that may negatively affect Better users will disqualify the report.
Handling Personally Identifiable Information (PII)
- Redact any personally identifiable information (PII) in your reports before submitting. If necessary to show proof of concept, leave a few characters visible and redact the rest.
- Report PII findings as soon as you discover them. Do not attempt to access additional data. Our internal teams will assess the scope and impact of the exposure.
- Limit the amount of PII data returned from services (e.g. limiting rows returned by SQL queries).
- You must delete all test-related data containing PII as soon as possible.
For the initial prioritization/rating of findings, this program will use the Bugcrowd Vulnerability Rating Taxonomy. However, it is important to note that in some cases a vulnerability priority will be modified due to its likelihood or impact. In any instance where an issue is downgraded, a full, detailed explanation will be provided to the researcher - along with the opportunity to appeal, and make a case for a higher priority You may look at the Severity scoring guidelines section to have a better understanding of how submissions will be rated .
|Technical severity||Reward range|
|p1 Critical||$1,200 - $1,500|
|p2 Severe||$800 - $1,000|
|p3 Moderate||$300 - $500|
|p4 Low||$100 - $150|
- better.com - The landing page for all of Better's services. Researchers are invited to test the entirety of this domain, including any and all subdomains.
- api.better.com - One of the API endpoints utilized by Better's applications.
- better.com/api - The other API endpoint utilized by Better's applications.
- arbitrary / remote code execution
- SQL Injection
- significant authentication bypass
- server side request forgery (SSRF)
- cross-site request forgery (CSRF)
- cross-site scripting (XSS)
- local file inclusion
- remote file inclusion
- authorization flaws
- access control issues (including insecure direct object references)
- access to sensitive production user data (including PII)
- access to internal production systems
- directory traversal
- significant security misconfiguration with a verifiable vulnerability
- sensitive data disclosure (credentials, secrets, keys, etc.) that pose a valid risk to an in scope asset
Out of Scope vulnerabilities:
- Denial of service attacks
- Phishing attacks
- Social engineering attacks
- Attacks requiring physical access
- Username enumeration via Login / Forgot Password error messages
- Vulnerabilities in third party integrations or client-side plugins (bypass site analytics with ?bypassAnalytics=true)
- Vulnerabilities third party libraries without working proof of concept
- SPF, DKIM or DMARC record issues (email spoofing)
- Missing security headers which do not lead directly to a vulnerability
- Unconfirmed reports from automated vulnerability scanners
- Self-XSS, including payloads entered by the victim
- Weak Captcha / Captcha bypass
- Logout CSRF
Acceptable Proofs of Concept (PoCs)
Below are the acceptable commands and file locations that must be used when testing and showing proof-of-concept for the following vulnerability categories:
|Category||Acceptable commands and operations|
|Command execution||whoami, hostname , uname|
- Please sign up for an account using your @bugcrowdninja.com email address. For more info regarding @bugcrowdninja email addresses, see here.
After validating a submission, the Better security team may issue a bonus reward in addition to the original bounty reward. Bonuses are given at the sole discretion of our Security/Engineering teams to reward bounty hunters that go above and beyond to discover impressive bugs, produce stellar reports, work well with our team, etc. Submissions that chain multiple vulnerabilities may also be eligible for a reward bonus.
Severity scoring guidelines
Severity scores and reward amounts are determined by the Better security team. Severity scores are calculated by evaluating two primary factors: impact to our customers and CVSS 3.1 base score. The following is a rough guideline we use internally for determining scores assigned to valid bounty submissions:
Critical (9.0 - 10)
Critical findings present a direct and immediate risk to Better or the majority of Better users
(typically greater than 50%). They often affect core/critical components in production application stacks or infrastructure. Examples include:
- arbitrary code/command execution on a Better server in our production environment
- access to sensitive production user data or access to internal production systems
High (7.0 - 8.9)
High findings typically impact many Better users. They often allow an attacker to read or modify highly sensitive data without authorization. Examples include:
- accessing another user's data
- bypassing authentication or authorization logic
- discovering sensitive user or Better data in a publicly exposed resource (e.g. S3 bucket)
- gaining access to a non-critical resource that only Better employees should be able to reach
- injecting attacker controlled content into Better.com (XSS) which bypasses CSP.
Medium (4.0 - 6.9)
Medium findings impact a small number of Better users. They often allow an attacker to read or modify limited amounts of data without authorization. Examples include:
- bypassing CSRF validation for low risk actions
- limited information disclosure from user or application features that should be inaccessible
- injecting attacker controlled content into Better.com (XSS) but not bypassing CSP or executing sensitive actions with another user's session
Low (0.1 - 3.9)
Low findings impact no Better users.
By submitting a report, you agree that you will not publicly disclose your findings or the contents of the report to any third parties without prior written approval from Better.
When conducting vulnerability research according to this policy, we consider this research to be:
- Authorized in accordance with the Computer Fraud and Abuse Act (CFAA) (and/or similar state laws), and we will not initiate or support legal action against you for accidental, good faith violations of this policy;
- Exempt from the Digital Millennium Copyright Act (DMCA), and we will not bring a claim against you for circumvention of technology controls;
- Exempt from restrictions in our Terms & Conditions that would interfere with conducting security research, and we waive those restrictions on a limited basis for work done under this policy; and
- Lawful, helpful to the overall security of the Internet, and conducted in good faith.
- You are expected, as always, to comply with all applicable laws.
If at any time you have concerns or are uncertain whether your security research is consistent with this policy, please submit a report through this program, or inquire via firstname.lastname@example.org before going any further.