No technology is perfect, and FetLife believes that working with skilled security researchers across the globe is crucial in identifying weaknesses in any technology. If you believe you've found a security issue in our product or service, we encourage you to notify us. We welcome working with you to resolve the issue promptly.
Response Targets
FetLife will make a best effort to meet the following SLAs for hackers participating in our program:
| Type of Response | SLA in business days |
|---|
| Time to first response | 5 days |
| Time to triage | 10 days |
| Time to bounty | 15 days |
| Time to resolution | depends on severity and complexity |
Program Rules
- Reports must include concrete and clear reproducible steps that do not require any commercial tools
- Reports must include a clear security impact, for example unauthorised access, data exposure, account takeover, or privilege escalation
- Register all accounts using your <hackerone_username>[email protected] address.
- Not interact with other accounts without the explicit consent of their owners.
- Communicate with FetLife's engineering team exclusively via HackerOne.
- Be the first person to report the issue to us. In cases where you submit a vulnerability that is already acknowledged, we will only award a bounty if it: proves to be more extensive, or provides more information.
- If the vulnerability affects multiple FetLife domains or subdomains, include them in a single report. We will assess the overall impact and award a bounty that matches the severity and scope.
- Do not use shared fake / temporary phone services. If our website requires you to enter a phone number, contact us at [email protected] and we'll take care of it. You are responsible for your test accounts at fetlife.com, so please use common security practices to secure those accounts.
Disclosure Policy
- Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.
- Provide us a reasonable amount of time to resolve the issue before any disclosure to the public or a third-party.
- Make a good faith effort to avoid privacy violations, destruction of data, interruption or degradation of our service.
- Only interact with accounts you own or with the explicit permission of the account holder.
Bounty Reward Program
To show our appreciation of responsible security researchers, FetLife offers a monetary bounty for reports of qualifying security vulnerabilities.
| Vulnerability Type | Average Bounty |
|---|
| Remote Code Execution (RCE) on FetLife Servers | $6,000 |
| SQL Injection (with output) | $4,000 |
| SQL Injection (blind) | $2,000 |
| Privilege Escalation Flaw | $1,500 |
| User Impersonation Vulnerability | $1,500 |
| Server Side Request Forgery (SSRF) | $1,000 |
| Local file Inclusion | $500 |
| Stored Cross Site Scripting | $500 |
| Stored Self Cross Site Scripting | $150 |
| Self Cross Site Scripting | $50 |
| Sensitive Data Exposure | $500 |
| Cross-Site Request Forgery (CSRF) | $500 |
| Improper Direct Object Reference (IDOR) | $500 |
| Security-impacting Business Logic Errors | $50 - $500 |
| User-Activity Exposure Flaw | $200 |
| Open Redirect | $150 |
| User-Specific Authorization Bypass | $100 |
| Generic Authorization Flaw | $100 |
| Other | $100+ |
To clarify the distinctions among the specified vulnerability types, predominantly within the group that would fit the description of "authorization flaws", refer to the following list:
- Generic Authorization Flaw - A catch-all category encompassing miscellaneous authorization flaws with minimal impact on our user.
- User-Specific Authorization Bypass - Any vulnerability pertinent to the user in question without data leaks. Actions such as editing one's own comments from banned groups are examples.
- User-Activity Exposure Flaw - Resembling User-Specific Authorization Bypass, yet unveiling actions or data concerning other users. For instance, viewing likes on a comment from a group one is banned from, or receiving notifications from closed groups (without the ability to view the content).
- Sensitive Data Exposure - Entails the ability to view content in unauthorized zones or on a broader scale than the User-Activity Exposure Flaw.
- User Impersonation Vulnerability - Pertains to masquerading as another user, except if the sole attack vector differs from the types listed in the table above. For instance, employing XSS from your primary account on your secondary account to access the latter account will be classified as XSS, not this vulnerability. However, being able to log in as a different user qualifies.
- Privilege Escalation Flaw - Refers to unauthorized elevation of permissions, like assuming the role of a caretaker. However, if such action results from executing an XSS or a similar attack on an elevated user, it won't be categorized here.
NOTE: In line with HackerOne's guidelines, post-triage of reports, we reserve the right to label reports as duplicates if they would be resolved due to another preceding report. For example, if a singular flaw in our code affects our entire website, we will address only the first report and label subsequent ones as duplicates. Triage implies successful replication of the issue and does not guarantee a reward. Rewards will be allocated solely when our developers confirm the issue is unique and have started working on them.
Out of Scope
We do not consider the following to be eligible vulnerabilities under this program:
- General product bugs and UI issues
- SEO and indexing issues
- Feature requests and usability feedback
- Performance issues without a demonstrated security impact
- Denial of Service
- Email spoofing
- Spamming
- Rate-limiting
- Click-jacking
- Content spoofing
- SPF, DMARC or other email configuration related issues
- Lack of DNSSEC
- SSL configuration issues
- Disclosure of server or software version numbers
- Generic examples of Host header attacks without evidence of the ability to target a remote victim
- Password or account recovery policies, such as reset link expiration or password complexity
- Theoretical sub-domain takeovers with no supporting evidence
- Perceived security weaknesses without evidence of the ability to target a remote victim. For example credentials are transmitted in POST body as plain text over TLS without demonstrating impact, etc.
- Reports exploiting unsupported browsers
- False reports, or reports lacking evidence of a vulnerability
- Attacks requiring a Man-in-the-Middle, with no other possible exploitation
- CSV injection that affects third-party applications
- Android Application (https://github.com/fetlife/android)
- iOS Application (https://github.com/fetlife/ios
- Configuration issues on end users machines. For example password storage or cache settings.
- Race conditions allowing bypass of numerical limits or counters (e.g., multiple poll votes, exceeding invite/favorite/collection limits) without exposure of sensitive data or escalation of privileges
- Reports of credentials, personal data, or other information obtained from third-party breaches, stealer logs, or OSINT sources (e.g., collections found on sites like DeHashed, intelx.io, Phonebook.cz). While these may involve FetLife members, they originate outside our systems. We encourage responsible disclosure of issues directly affecting our platform.
Disqualifiers
- Interacting with other accounts without the explicit consent of their owners.
- Denial of service
- Social engineering of any kind
- Physical intrusion
- Automated scanning and brute-forcing
- Requests to
/ads/serve, /ads/application_serve*, and /ads/click/*
- Overwhelming our support team with messages
- Mentioning PHP
Questions
- You can contact us with any questions at [email protected]
We offer a bounty of up to $6000 for helping us to protect our community.