DataCamp Responsible Disclosure Policy
Responsible Disclosure
DataCamp takes pride in proactively resolving all security vulnerabilities in our products. We are in the process of creating a formal security reward program. Until this program is live, we ask that you send all vulnerability findings to [email protected]. Any submission must contain reproduction steps, a proof of concept, and impact. We do not consider defense-in-depth practices that DataCamp, for various reasons, might decide not to have implemented as security vulnerabilities, for example, specific headers, cookie configurations, etc.
Out of scope Domains
*.it.datacamp.com
status.datacamp.com
intranet.datacamp.com
jira.datacamp.com
confluence.datacamp.com
Application
Self-XSS that cannot be used to exploit other users
Verbose messages/files/directory listings without disclosing any sensitive information
CORS misconfiguration on non-sensitive endpoints
Missing cookie flags
Missing security headers
Cross-site Request Forgery with no or low impact (e.g. Logout)
Presence of autocomplete attribute on web forms
Reverse tabnabbing
Bypassing rate-limits or the non-existence of rate-limits
Best practices violations (password complexity, expiration, re-use, etc.)
Clickjacking on pages with no sensitive actions
CSV Injection
Host Header Injection
Sessions not being invalidated (logout, enabling 2FA, ..)
Hyperlink injection/takeovers
Mixed content type issues
Cross-domain referer leakage
Anything related to email spoofing, SPF, DMARC or DKIM
Content injection
Username / email enumeration
E-mail bombing
HTTP Request smuggling without any proven impact
Homograph attacks
XMLRPC enabled
Banner grabbing / Version disclosure
Open ports without an accompanying proof-of-concept demonstrating vulnerability
Weak SSL configurations and SSL/TLS scan reports
Not stripping metadata of images
Disclosing API keys without proven impact
Same-site scripting
Subdomain takeover without taken over the subdomain
Arbitrary file upload without proof of the existence of the uploaded file
General
In case that a reported vulnerability was already known to the company from their own tests, it will be flagged as a duplicate
Theoretical security issues with no realistic exploit scenario(s) or attack surfaces, or issues that would require complex end user interactions to be exploited, may be excluded or be lowered in severity
Spam, social engineering and physical intrusion
DoS/DDoS attacks or brute force attacks
Vulnerabilities that are limited to non-current browsers (older than 3 versions) will not be accepted
Attacks requiring physical access to a victim's computer/device, man in the middle or compromised user accounts
Recently disclosed zero-day vulnerabilities in commercial products where no patch or a recent patch (< 2 weeks) is available. We need time to patch our systems just like everyone else - please give us 2 weeks before reporting these types of issues
Reports that state that software is out of date/vulnerable without a proof-of-concept
Mobile
Shared links leaked through the system clipboard
Any URIs leaked because a malicious app has permission to view URIs opened
The absence of certificate pinning
Sensitive data in URLs/request bodies when protected by TLS
Lack of obfuscation
Path disclosure in the binary
Lack of jailbreak & root detection
Crashes due to malformed URL Schemes
Lack of binary protection (anti-debugging) controls, mobile SSL pinning
Snapshot/Pasteboard leakage
Runtime hacking exploits (exploits only possible in a jailbroken environment)
API key leakage used for insensitive activities/actions
Attacks requiring physical access to the victim's device