Vulnerability disclosure program
How to report security issues to Join, what we commit to in response, and the rules of engagement for good-faith research.
Preamble
Reporting and good-faith research
Security is core to our values at JOIN, and we appreciate the input of security researchers acting in good faith to help us maintain a high standard for the security and privacy of our users. This includes encouraging responsible vulnerability research and disclosure. This policy sets out our definition of good faith in the context of finding and reporting vulnerabilities, as well as what you can expect from us in return.
Section 01
Expectations
When working with us, according to this policy, you can expect us to:
- Extend Safe Harbor for your vulnerability research that is related to this policy;
- Work with you to understand and validate your report, including a timely initial response to the submission;
- Remediate discovered vulnerabilities in a timely manner.
Section 02
Official channels
Any vulnerability deemed to be in-scope should be reported to [email protected]. Please keep all communication about reported vulnerabilities private between yourself and JOIN until we have had a chance to address the issue. Provide detailed reports with reproducible steps. If the report is not detailed enough to reproduce the issue, the issue will not be eligible for a reward.
Section 03
Guidelines
To encourage vulnerability research and to avoid any confusion between legitimate research and malicious attack, we ask that you attempt, in good faith, to:
- Play by the rules. Adhere to this policy and any other relevant agreements, e.g., Terms of Service;
- Report any vulnerability you have discovered promptly;
- Avoid violating the privacy of others, disrupting our systems, destroying data, and/or harming user experience;
- Use only the Official Channels to discuss vulnerability information with us;
- Handle the confidentiality of details of any discovered vulnerabilities according to the Coordinated Disclosure section below;
- Perform testing only on in-scope systems, and respect systems and activities which are out-of-scope;
- If a vulnerability provides unintended access to user data, such as Personally Identifiable Information (PII), or proprietary information, you must stop testing, submit a report immediately, and not save, store, transfer, or otherwise access the data;
- Only interact with accounts you own unless given explicit permission by the account holder;
- Do not engage in extortion;
- Be clear and succinct. A short proof-of-concept link is invaluable;
- Never attempt non-technical attacks (social engineering, phishing, physical attacks) against our employees, users, or infrastructure;
- Do not view, alter, save, store, transfer, or otherwise access our data or the data of our users without explicit permission.
We may modify the terms or terminate this program at any time.
Section 04
Safe harbor
When conducting vulnerability research according to this policy, we consider the research conducted under this policy to be:
- Authorized in view of any applicable anti-hacking laws, and we will not initiate or support legal action against you for accidental, good-faith violations of this policy;
- Authorized in view of relevant anti-circumvention laws, and we will not bring a claim against you for circumvention of technology controls;
- Exempt from restrictions in our Acceptable Usage Policy that would interfere with conducting security research, and we waive those restrictions on a limited basis;
- 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 a third party initiates legal action against you and you have complied with this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
If at any time you have concerns or are unsure whether your security research is consistent with this policy, please email us at [email protected] before going any further.
Section 05
In-scope
This program applies only to vulnerabilities affecting systems hosted on join.com.
Any design or implementation issue that substantially affects the confidentiality or integrity of user data is likely to be considered in-scope. Common examples include:
- Cross-site scripting.
- Cross-site request forgery.
- Mixed-content scripts.
- Authentication or authorization flaws.
- Server-side code execution bugs.
- Circumvention of our permissions model.
- SQL injection.
- XML external entity attacks.
While this list reflects the research we prioritize, it should not be considered exhaustive. Any report that concerns the possible compromise of user data is likely to be in-scope.
Section 06
Out-of-scope
The following issues are explicitly outside the scope of this program:
- Policies on presence/absence of SPF/DMARC records.
- Password, email, and account policies, such as email id verification, reset link expiration, and password complexity.
- Logout cross-site request forgery.
- Attacks requiring physical access to a user’s device.
- XSS on any site other than join.com.
- Attacks that require an exploitation tool to overlay on top of our app (e.g., tapjacking).
- Vulnerabilities that require a potential victim to install non-standard software or otherwise take active steps to make themselves susceptible.
- Vulnerabilities affecting users of outdated browsers or platforms.
- Social engineering of our employees or contractors.
- Any physical attempts against our property or data centers.
- Presence of autocomplete attribute on web forms.
- Missing cookie flags on non-sensitive cookies.
- Any access to data that requires the targeted user to be operating a rooted mobile device.
The following issues are outside the scope of our program, unless they are accompanied by evidence of exploitability:
- Use of a known-vulnerable library.
- Missing best practices.
- Insecure SSL/TLS ciphers.
- Missing security headers, which do not directly lead to a vulnerability.
- Lack of CSRF tokens, except when there is evidence of a sensitive user-action not protected by a token.
- Host header injections.
- Reports from automated tools or scans that haven’t been manually validated.
- Presence of banner or version information, unless a vulnerable version.
Section 07
Coordinated disclosure
Researchers may share vulnerability details with third parties only after the vulnerability has been fixed and the Program has granted approval. We will work with you to set a reasonable disclosure timeline based on the severity and complexity of the issue.
Questions about this program? Reach our security team at [email protected].