Sprinklr’s Vulnerability Disclosure Program
The Submission Process
If you believe you have found a vulnerability, immediately create a submission through our Hackerone platform. You can submit a bug through hackerone.
You will be recognized for your efforts if you were the first to report a valid vulnerability as per the rules of the vulnerability disclosure program.
Guidelines for Responsible Disclosure
All the security researchers should strictly follow the guidelines given below:
- Security research should be performed within the scope defined below.
- While performing the research there should not be any disruption of systems, privacy violations and degradation to user experience.
- The identified communication channels are the “submit” URL link or the “submission form” for submitting a vulnerability.
- DO NOT report a security vulnerability to any other Sprinklr’s partner, client, employee and email.
- Security vulnerability found in Sprinklr’s APIs utilized on our partner and customer website also fall under this responsible disclosure program.
- DDoS attacks DO NOT qualify under this program and website should not be tested against such attacks.
- Information about the vulnerability should not be disclosed publicly.
- Information about finding a vulnerability also should not be disclosed publicly.
- The researcher should not put the screenshots, videos, screen grabs or any other sensitive information regarding the vulnerability on any external websites like Imgur, Vimeo, YouTube, Dropbox, etc.
- Violation of the stated policy (both general guidelines and program policy) can result in enforcement of necessary legal actions.
When reporting vulnerabilities, please consider (1) attack scenario / exploitability, and (2) security impact of the bug. The following issues are considered out of scope:
- Clickjacking on pages with no sensitive actions
- UI and UX bugs and spelling mistakes
- Cross-Site Request Forgery (CSRF) on unauthenticated forms or forms with no sensitive actions
- Attacks requiring MITM or physical access to a user’s device
- Previously known vulnerable libraries without a working Proof of Concept
- Comma Separated Values (CSV) injection without demonstrating a vulnerability
- Missing best practices in SSL/TLS configuration
- Any activity that could lead to the disruption of our service (DoS)
- Content spoofing and text injection issues without showing an attack vector/without being able to modify HTML/CSS
- Rate limiting or bruteforce issues on non-authentication endpoints
- Missing best practices in Content Security Policy
- HttpOnly or Secure flags on cookies
- Missing email best practices (Invalid, incomplete or missing SPF/DKIM/DMARC records, etc)
- Vulnerabilities only affecting users of outdated or unpatched browsers [Less than 2 stable versions behind the latest released stable version]
- Software version disclosure / Banner identification issues / Descriptive error messages or headers (e.g. stack traces, application or server errors)
- Public Zero-day vulnerabilities that have had an official patch for less than 1 month will be awarded on a case by case basis
- Open redirect – unless an additional security impact can be demonstrated
- Issues that require unlikely user interaction
- Vulnerabilities relying highly on social engineering aspect
- Username enumeration
- Vulnerabilities relying on the existence of plugins such as Flash
- Security headers/attributes missing such as, but not limited to “content-type-options”, “X-XSS-Protection”
- CAPTCHAs missing as a Security protection mechanism
- Use of a known-vulnerable library without proof of exploitability;
- Vulnerabilities in third-party software, libraries and code
- Self-type Cross Site Scripting / Self-XSS
- Cache Poisoning
- Vulnerabilities on sites hosted by third parties unless they lead to a vulnerability on the main website
- Vulnerabilities contingent on physical attack, social engineering, spamming, DDOS attacks, etc