Our number one priority is to ensure the security of the SendSafely platform. Our Bug Bounty program is designed to reward researchers for discovering and reporting vulnerabilities that present a high risk to the overall security of our platform and our users. In order to be eligible for a reward, your vulnerability must meet the qualification requirements outlined below and you must follow our reporting and disclosure procedures.

Program Rules

The SendSafely program follows a set of well defined and industry standard disclosure terms and vulnerability rating taxonomies. To avoid confusion, SendSafely will rate all submissions using the Bugcrowd Vulnerability Rating Taxonomy.

Each submission will be evaluated by the SendSafely security team on the basis of first-to-find. You will qualify for a reward if you were the first person to alert us of a previously unknown issue and the issue triggers us to make a code or configuration change to our platform.

Our Bug Bounty program pays cash rewards issues with a Technical Severity of P1, P2 and P3. Issues rated P4 or lower may be submitted, but will not likely be eligible for a cash reward. Our standard payout policy is below.

Severity	Cash Reward
P1	$1,500
P2	$500
P3	$200

We ask that you please abide by the following rules when participating in the SendSafely bug bounty program:

• Testing should be performed only on systems listed as in scope under the "Testing Targets" section. Any other systems are Out Of Scope.
• Except when otherwise described, you should create accounts for testing purposes.
• Submissions must be made exclusively to our team using our Security Bug Reporting Form to be considered for a reward. Please use the SendSafely platform itself to create and send us the specific details of the vulnerability and any required reproduction steps.
• Actions which affect the integrity or availability of the SendSafely platform are prohibited and strictly enforced. If you notice performance degradation on the target systems, you must immediately suspend all use of automated tools.
• Submissions should have impact to the SendSafely platforms security posture. Impact means the reported issue affects SendSafely users, systems, or data security in a meaningful way. Submitters may be asked to defend the impact in order to qualify for a reward.
• Submissions may be closed if a researcher is non-responsive to requests for information after 7 days.
• We encourage Researchers to include a video or screenshot Proof-of-Concept in their submissions. These files should not be shared publicly. This includes uploading to any publicly accessible websites (i.e. YouTube, Imgur, etc.).
• Violation of the SendSafely programs disclosure policy may result in enforcement action.
• A violation of these rules may result in the invalidation of submissions, and forfeiture of all rewards.

Testing Targets

All URLs hosted under www.sendsafely.com are included within the scope of our bug bounty program. Please keep in mind that this is a production environment. When performing your testing, we ask that you:

• Do not use vulnerabilities to access, modify, harm, or otherwise alter any data that does not belong to you.
• Do not exploit vulnerabilities except for purposes of demonstrating it to us.
• Do not conduct network level or Denial of Service testing or traffic flooding attacks against our systems.
• Do not conduct any tests that will impact the performance of the environment, such as aggressive scanning and/or aggressive scripting.
• Do not target other SendSafely users or SendSafely customers. All SendSafely customers are out of scope and should not be targeted under any circumstances.

Please also note that the following findings are specifically excluded from the bounty:

• Findings identified through physical testing of office access (e.g. open doors, tailgating).
• Attacks conducted using social engineering (e.g. phishing, vishing).
• Anything relating to an applications or system not listed in the above “Testing Targets” section.
• Functional, UI and UX bugs and spelling mistakes.
• Network level Denial of Service (DoS/DDoS) vulnerabilities.
• Descriptive error messages (e.g. Stack Traces, application or server errors).
• HTTP 404 codes/pages or other HTTP non-200 codes/pages.
• Fingerprinting / banner disclosure on common/public services.
• Disclosure of known public files or directories, (e.g. robots.txt).
• CSRF on forms that are available to anonymous users (e.g. the contact form) and the Login/Logout URL.
• Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
• Lack of HTTPOnly cookie flags.
• Lack of Security Speedbump when leaving the site.
• Login Brute Force (unless the CAPTCHA can be bypassed)
• OPTIONS HTTP method enabled
• Missing X-Content-Type-Options Header
• Use of SHA-1 SSL Certificate and support for TLS 1.0

Submitting a Bug Report

All submissions must be made using our Security Bug Reporting Form. You'll be expected to explain where the bug is, who it affects, how to reproduce it, the parameters it affects, and any PoC code. You can also upload any files that you may have that proves the vulnerability exists. You want to add as much information as you can to help reproduce the vulnerability. This not only helps the company quickly reproduce the issue but also helps moves your submission through the review process a lot faster.

The following information will be required for all valid bug submissions.

Caption	The title of the report should describe the type of bug found, where it was found, and the overall impact. For example, “Remote File Inclusion in Resume Upload Form allows remote code execution” is much more descriptive and helpful than “RFI Injection found."
Target	The Target field identifies the specific target affected by the bug you have found.
Bug Type	The bug type identifies the kind of bug you have found. It is important that you choose the correct bug type so that the organization understands the risk the bug presents them.
Bug URL	The bug URL identifies the location in the application where you discovered the bug.
Proof of Concept	Your report must include clear and descriptive replication steps so that the organization can easily reproduce and validate that your findings.
Additional Info	The section where you can provide context. You can explain what you discovered and describe the impact and risk of your discovery.
Screenshots	If possible, you should include illustrative evidence that shows proof of the vulnerability.