Front is a customer operations platform used by over 8,000 teams to streamline communication.
It combines the efficiency of a help desk and the familiarity of email so teams can deliver exceptional service at scale.
See here for a quick overview of our product!
Our customers trust us with their private communications, and we are especially interested in reports of vulnerabilities that would disclose cross-company/cross-tenant data.
Program Rules
- By submitting reports or otherwise participating in this program, you agree that you have read and understand our bug bounty policies. Violation may result in ineligibility for bounty payout and/or removal from our program.
- Do not disclose information about vulnerabilities you discover publicly, or to any 3rd party without prior written authorization from Front. This includes not uploading or storing evidence or information about your findings on external platforms outside of your report on HackerOne (e.g. exploit videos on YouTube).
- Only test on accounts you own, or accounts you have permission from the owner to test on.
- If sensitive or private data is found, do not store, transfer, process, or otherwise retain any copy or information derived from the data for other purposes than reporting your finding to us.
- Do not engage in disruptive or damaging activities that would affect Front or otherwise degrade service to our customers.
- Do not download/modify customer data or otherwise interact with Front's customers. For example, posting comments/messages in customer accounts.
- This includes phishing/social engineering attacks, physical security breaches, spamming, and general resource exhaustion/denial of service attacks.
- Please be aware that your access may be blocked without advance warning or explanation if such activity is detected.
- When in doubt, report your findings and request additional permission to continue testing.
- DO NOT test any website that is out of scope or not listed in assets.
- We will accept and reward credential reports exclusively for instances where valid and previously unknown Front.com employee credentials are found. Submissions must include the source of the leaked credentials, and hackers are strictly prohibited from testing credential validity. We will no longer be accepting credential reports for non-front.com credentials. If credentials (e.g. username & password files, urls containing tokens) are found on 3rd party web sites, please report them to us but do not attempt to validate them by logging in or accessing a URL. Delete any artifacts after submitting a report to us.
Credentials should be submitted in 1 CSV file in the following format:
email,password
[email protected],password123
We reserve the right to modify the terms of our program at any time without notice.
Safe Harbor
Any activities conducted in a manner consistent with this policy will be considered authorized conduct and we will not initiate legal action against you. If legal action is initiated by a third party against you in connection with activities conducted under this policy, we will take steps to make it known that your actions were conducted in compliance with this policy.
How to Test
- Sign up for an account here: https://front.com/signup?affiliate=partners
- Ensure that you include the
[Bug Bounty] SomeCompanyName pattern as a company name and that you use your @wearehackerone.com alias email address. Any accounts that don't adhere to this will be terminated without prior notice.
- DO NOT test any website that is out of scope or not listed in assets.
To learn more about how Front is used, check out Front Academy!
Rewards
The following table is a guide for how we determine the severity of a vulnerability, assuming no mitigating factors:
| Vulnerability | Severity |
|---|
| Server-side RCE on core Front application | Critical |
| Cross-company full message/discussion disclosure | Critical |
| Message/Discussion disclosure of personal inbox of any user of attacker’s choice with no/unprivileged credentials | Critical |
| Client-side RCE without user interaction | High |
| XSS exploitable by an external party | High |
| Cross-company sensitive data disclosure (non-message/discussion) | High |
| Low privilege user able to execute sensitive admin actions through API (e.g. granting/revoking access) | High |
| Intra-company XSS against another teammate | Medium |
| Low-privilege user able to view sensitive admin-only data (e.g. message snippets) | Medium |
| Client-side denial of service (e.g. HTML message rendering bugs) without workaround | Medium |
| Low-privilege user able to execute non-sensitive admin actions (please read Non-sensitive API Data section below) | Low |
| Low-privilege user able to view non- sensitive admin-only data (please read Non-sensitive API Data section below) | Low |
| XSS with high user interaction | Low |
| Credentials found on 3rd party sites | Low |
Final determination of severity and payout is at the discretion of Front.
- We may choose to increase bounties for well-written reports providing more details and evidence of impact.
- Similarly, bounties may be decreased for reports of vulnerabilities with mitigating factors or requiring complex interaction or additional contingencies to exploit.
Reports of vulnerabilities in third-party or vendor services are not eligible for bounties, although we may choose to award a token payout for the information at our discretion.
If you find a vulnerability in an asset owned by Front but not explicitly mentioned in our program scope, please report it and we will consider its addition to our program.
Bounty Eligibility Clarification
All cross-company/cross-tenant access is of security concern to us.
Below clarifies what we consider to be intra-company security issues.
Global Admin Access
As a general rule, we believe companies own their Front data, and Global Admins are expected to have high levels of access to this data (including even reading another teammate’s personal message).
- This is also true of Workspace Admins and teammates in that workspace.
- However, we would not expect a non-privileged teammate to be able to read personal messages of others.
Non-sensitive API Data
It is common and expected for an API to return information that is not necessarily available in the UI, and this may not constitute a security issue. Here are some examples:
- Within a company, all teammates are visible to all. This includes teammates in different workspaces, invited teammates, as well as teammates who have left the company.
- Within a company, all inboxes' metadata are visible to all. This includes "private" inboxes and deleted inboxes.
- Within a company, all channels associated with any inbox are visible to all. This includes channels attached to private inboxes.
- Within a company, rules, macros, and workflows may be visible to teammates who cannot modify them.
- Forwarding addresses
While the above may be surprising, this is currently how our product works. We do not consider these a security issue.
Teammate Configuration Data
Teammates are expected to be able to view (not modify) another’s configuration data (e.g. vacation settings), even if the victim teammate has left the company.
Topics
Topics, also known as links (e.g. from Asana, Todoist integrations), are a separate feature from Tags, and do not have user-defined access control. Anyone within a company can add/edit/remove topics from a conversation.
Plugins
Please do not report Admins adding unapproved malicious plugins to attack their own company’s teammates.
Non-qualifying Reports
Please do not report the following:
- Missing security best practices, HTTP(S) security headers, DNS or SSL/TLS or server configs without proof of exploit
- Use of 3rd-party library/package/middleware with known vulnerability without proof of exploit
- Content spoofing/text injection without showing attack vector
- Clickjacking on pages with no sensitive actions
- Login CSRF
- Missing CSRF tokens without proof of exploit
- Physical/Social engineering (e.g. phishing, vishing, smishing, spoof/impersonation) attacks, whether on Front staff or other victim accounts
- Automated scan results
- Attacks requiring MITM or physical access to a user's device
- Comma Separated Values (CSV) injection without proof of exploit
- Insufficient/Missing password strength policy
- Self-XSS (non persisted)
- Accessing features outside of plan
- Bypassing plan limits to invite extra teammates
- Spam