Disclosing Security Vulnerabilities
We encourage security researchers to report or disclose security vulnerabilities to us and we also offer a
bounty program to those who are eligible, please read on to learn more about the rules, guidelines and other
Rules when reporting vulnerabilities
- Avoid gaining access to another user’s account, devices, or data.
- Do not perform attack that can impact the availability and reliability of our services or data. Running automated DDoS or SPAM attacks are not allowed.
- Do not publicly disclose the bug before it gets fixed.
- Do not use scanners or automated tools to find vulnerabilities as it creates lot of noise in our logs and we’ll be forced to ban your IP or suspend your account.
- Attempts such as non-technical attacks i.e social engineering, phishing, attacks against our employees and users are not allowed.
- Only sites listed below are allowed for security testing:
- Have any questions, feel free to contact firstname.lastname@example.org.
Rules for us to follow
- We’ll respond as quickly as possible, but do give us 48hours to respond.
- We’ll keep you posted as we roll out the fix for the bug you reported.
- We’ll not take any legal action against you if you adhere to the rules.
Exclusions & Out-of-Scope
- Previously reported issues which we’re already aware of or are in the process of fixing or have determined to be not eligible are out of scope.
- Vulnerabilities on subdomains or assets that are not explicitly listed in the scope.
- Issues that resolve to third-party services like Hubspot, Intercom, Calendly etc.
- Any activity that could lead to the disruption of service (DoS/DDoS).
- User Enumeration via Login Page/Forgot Password page error message.
- Timing attacks to prove the existence of a user.
- A session is still valid after logout.
- Clickjacking due to a lack of X-Frame-Options use.
- Missing Security HTTP Headers.
- Missing Best Practises like Password Strength and complexity.
- TLS cookie without HttpOnly or Secure flag set
- Insecure cookie settings for non-sensitive cookies.
- CSRF in unauthenticated or non-sensitive forms including Login/Logout CSRF.
- Previously known vulnerable libraries without a working Proof of Concept.
- Mail configuration issues including SPF, DKIM, DMARC settings.
- Comma Separated Values (CSV) injection without demonstrating a vulnerability.
- Open redirection due to Header Injection: X-Forwarded-Host, X-Host, X-Server.
- Email Spoofing.
- Server Version Disclosure.
- Attacks requiring MITM or physical access to a user’s device.
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS.
- HTML Injection without any attack vector.
- Bugs that don’t affect the latest version of modern browsers (Chrome, Firefox, Edge, Safari).
- Bugs related to browser extensions are also out of scope.
- Disclosure of public information and information that does not present significant risk.
- Scripting or other automation and brute forcing of intended functionality.
- Password field with autocomplete enabled.
- Bugs requiring very unlikely user interaction.
- SSL BEAST/CRIME or missing best practices in SSL/TLS configuration.
- Usage of old/weak TLS ciphers.
- Weak Captcha / Captcha Bypass
- Email bombing and flooding.
- Password reset or confirmation token leakage via Referer header to a trusted 3rd party.
- If you’re an employee or ex-employee of Scalefusion (ProMobi Technologies).
- Have any questions, feel free to contact email@example.com
How to report issues?
Writing a good vulnerability report is extremely useful for the development team to understand and analyze the impact, it is also likely to be picked up quickly for fixing because a clearer report reduces the need of multiple communications. We suggest that you follow this excellent HackerOne guide on how to write a good vulnerability report.
Send your vulnerability report to: firstname.lastname@example.org
- How is the bounty reward determined?
Our development and security team considers multiple factors to determine the appropriate reward. We analyze the complexity of successfully exploiting the reported vulnerability, percent of impacted users, potential exposure and classification of vulnerabilities. A critical vulnerability may have a low impact area because of some other protections in place or it requires a special interaction or depends on outdated configuration in users systems.
- How the reward is paid?
The reward will likely be paid through PayPal, unless we notify you otherwise. You may have to fill up some paperwork for our accounting department for compliance purpose.
- Are there any legal terms for the Bounty payment?
When your reported issue is eligible for bounty and you accept the bounty payment then you have to read and agree to our terms of service agreement.
- If you’re participating from a country against which India has export sanctions put in place or trade restrictions then we’ll not be able to pay you the bounty amount.
- If you’re participating from a country against which United States or United Nations has export sanctions put in place or trade restrictions then we’ll not be able to pay you the bounty amount.
- You’re solely responsible for any applicable taxes, withholding or otherwise, including from any bounty payments.
- By reporting the issues you’ll not violate any applicable laws in your country or disrupt anything that you do not own.
The bounty amount can range from $50 - $1000, we reserve the right to change the limit in future. The bounty amount will be
determined based on the following classifications:
- Insecure Direct Object Reference
- Cross-site Scripting (XSS)
- Cross-site Request Forgery (CSRF)
- Security Misconfiguration
- Incorrect Session Management or Broken Authentication
- Missing or Incorrect Access Control
- Sensitive Data Exposure
- SQL Injection
- OWASP TOP 10
Have any questions, feel free to contact email@example.com.