Responsible Disclosure

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

  • 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
  • Tabnabbing
  • 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

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.

Thank you for helping keep Sprinklr safe!