airSlate, Inc. and its provider companies ("airSlate," "we," "our") welcome security researchers to responsibly research our products to report vulnerabilities and help make them safer for our users. 

We launched the airSlate Bug Bounty Program ("Program") to offer recognition and rewards for the discovery of eligible vulnerabilities as defined in this Program.

• Avoid compromising any personal data, interruption, or degradation of any service.
• Avoid using automated tools that create massive traffic.
• Don't violate the privacy of other users. For testing, use only your own created accounts.
• Don't use discovered vulnerabilities to harm our platform.
• Don't access or modify other users' data, or localize all tests to your accounts.
• Don't exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam.
• Don't publicly disclose discovered vulnerabilities or share private information.
• You must comply with all applicable laws in connection with your research activities and participation in this program.
• Don't harm and do not exploit any vulnerability beyond the minimal amount of testing required to prove that a vulnerability exists or to identify an indicator related to a vulnerability.
• Do not extract any data under any circumstances.
• Do not intentionally compromise the intellectual property or other commercial or financial interests of us or any third parties.
• Do not submit high-volume or low-quality reports.
• If at any point you are uncertain whether to continue testing, please engage with our team.

airSlate does not permit anyone to engage in any security research, vulnerability, or threat disclosure activity that is inconsistent with this Program or the law. airSlate reserves the right to update or modify this Program at any time.

This Program does not support, nor offer rewards for the following reported vulnerabilities:

• UI and UX bugs and spelling or localization mistakes.
• Frontend (client-side) workflow issues that are not vulnerabilities to private data
• API access to a user's basic profile (e.g., name, avatar, slug). 
• (Users may share public documents and a basic profile, which may include basic personal details (eg, name) on their public page)
• Public Browser Keys (such as GOOGLEBROWSERKEY, GOOGLECLIENTID, SENTRYAUTHTOKEN).
• Circumnavigate rate limits for DocHub Pro features and/or allow access to these features through request/response manipulation
• Access gained to a non-confidential client secret or API key
• Accessible non-sensitive files and directories (e.g., README.TXT, CHANGES.TXT, robots.txt, gitignore, etc);
• Attacks requiring MITM or physical access to a user's device
• Attacks requiring physical access to devices are considered out of scope for this Program
• Clickjacking and issues are only exploitable through clickjacking
• Comma-Separated Values (CSV) injection without demonstrating a vulnerability
• Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
• Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions;
• Denial of Service (DoS) attacks
• Descriptive error messages (e.g., stack traces, application or server errors, path disclosure);
• Email spoofing (including SPF, DKIM, DMARC, From: spoofing, visually similar, and related issues)
• Fingerprinting/banner disclosure on common/public services
• Gaining access to personally identifiable information by deceiving users into granting access (deception as opposed to theft)
• HTTPS mixed content scripts
• Internal IP address disclosure
• Issues that require unlikely user interaction
• MFA issues are out of scope at the present time
• Missing best practices in Content Security Policy or SSL/TLS configuration
• Missing email best practices (Invalid, incomplete, or missing SPF/DKIM/DMARC records, etc)
• Missing HTTP security headers
• Missing HttpOnly or Secure flags on cookies (critical systems may still be in scope)
• Open redirects (through headers and parameters) / Lack of a security speed bump when leaving the site;
• Out-of-date software
• Password and account recovery policies, such as reset link expiration or password complexity;
• Password strength requirements
• Previously known vulnerable libraries without a working Proof of Concept
• Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case-by-case basis
• Rate limiting or brute force issues on non-authentication endpoints
• Vulnerabilities that cannot be used to exploit other users
• Social engineering/phishing attacks
• Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g., stack traces, application or server errors)
• Tabnabbing
• Content injection issues
• Reflected File Download (RFD)
• Cross-site Scripting (XSS) - Reflected
• Cross-site Scripting (XSS) - DOM
• HTML injection - Reflected
• HTML injection - DOM
• Plain-text authentication via HTTP
• File and Directory Information Exposure
• Information Exposure Through Debug Information
• Session fixation
• TLS/SSL Issues, including BEAST BREACH, insecure renegotiation, bad cipher suite, expired certificates;
• Use of a known vulnerable component (exceptional cases, such as where you are able to provide proof of exploitation, may still be in scope);
• Username/email enumeration by brute forcing/error messages (e.g., login/signup/forgotten password);
• Vulnerabilities only affecting users of outdated or unpatched browsers (Less than 2 stable versions behind the latest released stable version);
• When a user shares a document publicly, the privacy of their name, email, and basic profile is out of scope;
• Most brute-forcing issues;
• Self-attack that cannot be used to exploit other users;
• Vulnerabilities that cannot be used to exploit other users or do not harm users;
• Cross-Site Request Forgery (CSRF). This vulnerability can be considered by the program only if there is a critical impact.
• Any vulnerabilities that arise solely from user-created pages on Instapage, such as reflected/stored XSS, open redirects, clickjacking, phishing, or spoofing, etc. 

Report intake under this Program is possible only via airSlate HackerOne Portal, and you will need an invitation to access it. 

To get an invitation link, please email hackerone@dochub.com first. 

Note: Before sending the report by email, make sure it is formatted correctly. The required elements are described in the What Must a Report Contain? section below. After you send the email, a HackerOne report will be generated automatically.

By submitting a report, you are indicating that you have read, understand, and agree to the terms of this Program.

Only reports that meet all of the following requirements are eligible to receive a monetary reward:

• You must be the first reporter of the vulnerability
• The vulnerability must demonstrate a security impact to a site or application that is within the scope of this Program, as described below.
• You must not have compromised the privacy of our users or otherwise violated our Privacy Notice or Data Protection Addendum.
• You must not have publicly disclosed the vulnerability.
• You must have otherwise complied with this Program and the applicable laws and all rules and provisions of this Program.

1. Summary: Your report should start with a brief summary introducing the reader to your findings.

2. Vulnerability Description: This section describes all the details related to your finding. Make the technical points clear and explain what causes the issue.

3. Proof of Concept: A Report with a Proof-of-Concept code will allow us to assess your submission more quickly and accurately.
The Proof-of-Concept section should contain:

• request and response (BurpSuite, OWASP Zap) with both positive and negative scenarios to examine its durability and document the results
• screenshots with the product's vulnerable functionality; and a video describing potential vulnerability exploitation.

4. Mitigation: You can link to the relevant OWASP Prevention cheat sheet or other security documents.

Please provide as much evidence as possible, including but not limited to: reproduction steps, screenshots, account information, and any other details that would allow us to verify your vulnerability.

If you have any questions, suggestions, or feedback, please contact us at security_report@airslate.com.
We do not accept reports via this email. Reports should be sent as described in the How to Submit a Bug Bounty Report? section above.

Thank you for helping us keep airSlate and our users safe.