Spotify

We're big believers in protecting your privacy and security. As a company, we not only have a vested interest, but also a deep desire to see the Internet remain as safe as possible for us all. So, needless to say, we take security issues very seriously.

In our opinion, the practice of 'responsible disclosure' is the best way to safeguard the Internet. It allows individuals to notify companies like Spotify of any security threats before going public with the information. This gives us a fighting chance to resolve the problem before the criminally-minded become aware of it.

Responsible disclosure is the industry best practice, and we recommend it as a procedure to anyone researching security vulnerabilities.

Targets

We are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted on domains owned by Spotify.

You can find more details under the Scope tab. Unless specified on the scope page, companies acquired by Spotify are not in scope.

We classify our assets as core versus non-core. The core assets were defined by the disruption to our customers and sensitivity level of exposed information in the event of successful exploitation. We would like for you to please prioritize searching for bugs on those assets since we feel it will improve the security of our organization.

We are particularly interested in the following categories of security bugs on our core-assets:

We're also interested in security vulnerabilities in our AI products and AI-enabled features. These include, but are not limited to: prompt injection, sensitive data disclosure, system prompt leakage, improper output handling with a demonstration of how it can impact other users, etc.

We encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==<spotify.okta.com>==, while adhering to the guidelines outlined below:

• Reports must focus solely on credentials for Spotify's corporate/internal systems; credentials for consumer or end-user accounts are strictly out of scope and will not be considered for rewards.
• Researchers are expected to obtain leaked credentials through ethical means only. Engaging in unauthorized activities, such as phishing, attacking end users, or trading in stolen credentials, is strictly prohibited. Every report must include the source of the leak (e.g., the specific website, forum, or repository where the credentials were discovered).
• Researchers may test the validity of credentials solely to the extent of confirming authentication, followed by immediate deauthentication, without accessing or utilizing any functionality of the system. Credentials purchased from illegal sources or obtained through unethical practices will result in disqualification from the program.
• We offer a flat bounty of $100 per unique source of leaked credentials. However, credentials that grant administrative access or access to sensitive information, such as mass PII, may warrant additional rewards based on the criticality of the issue. The severity of such reports will be evaluated on a case-by-case basis to determine an appropriate reward amount.

Rules of engagement

We are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.

To be eligible for a reward, note that we typically require the issue report to have some actual security impact in a realistic scenario. This does not mean you need to fully exploit issues. Simply provide the information you have, and we will analyze your report and draw conclusions on the impact. If you have found multiple vulnerabilities to report, report each one separately, for tracking and payment purposes. If you have a vulnerability to report that depends on chaining, report each link in the chain separately, and then a report for the whole chain. Expect that we will use reports to search for other instances of the same vulnerability class. Reports are not eligible for additional or higher payment when we find and fix other, unreported instances. If you found a vulnerability that affects multiple instances, bundle those instances and submit as one report.

We accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:

• playplay DRM system vulnerabilities on mobile client versions 9.0.0+
• playplay DRM system vulnerabilities on desktop client versions 1.2.53+

For issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.

HackerOne reporters should only upload personal data to the HackerOne platform if the personal data is necessary for the investigation and resolution of the vulnerability. HackerOne should never store Spotify user_id following the resolution of an incident.

##Third Party Dependencies

A critical element of security of a software package is the security of dependencies, so we maintain that vulnerabilities in 3rd-party dependencies are within scope for this program. That being said, we ask that bug reports are sent directly to the owner of the vulnerable package first and that you ensure that the issue is addressed upstream before letting us know of the issue details. We believe that the source code authors should have the advantage of learning about the vulnerabilities first.

Submissions of vulnerabilities through 3rd-party dependencies should:

• Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.
• Must be shared no earlier than 30 days after the issue was fixed upstream (e.g. a patched software package had been released greater than 30 days ago and we are still vulnerable).
• Vulnerabilities within 3rd-party services or platforms used to maintain and build Spotify applications are out of scope for this program. We cannot authorize the security testing and research of assets that belong to other users and companies. However, we welcome reports on vulnerabilities in our configuration or integration of those 3rd-party services.

Please understand that, while we can authorize your research on Spotify’s systems and services, we cannot authorize your efforts on third party products or guarantee they won’t pursue legal action against you.

##Third Party Managed Websites

Please note that there is a multitude of third party managed sites under the Spotify name and brand. If a bug you have submitted affects a site managed by a third party we will award you a $100 bonus payment and close the report as informational. third party sites are usually found under the following domains:

• *.withspotify.com
• *.byspotify.com
• *.atspotify.com

There can be third party assets under various domains not listed here and we ask for your patience as we determine their status.

There are some things we explicitly ask you not to do:

• When experimenting, please only target accounts belonging to you. Do not use leaked or compromised accounts belonging to other users. Vulnerabilities that were discovered using leaked or compromised accounts will be disqualified.
• Do not run automated scans. They are often very noisy.
• Do not test the physical security of Spotify offices, employees, equipment, et.c.
• Do not test using social engineering techniques (phishing, vishing, et.c.)
• Do not perform DoS or DDoS attacks.
• In any way attack our end users, or engage in trade of stolen user credentials.

The following finding types are specifically excluded from the bounty:

• Reports of compromised accounts, accounts exposed in data breaches, or publicly accessible password dumps are not in scope for the bug bounty program, but can be reported through our support site or [email protected].
• Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect (Other redirect vulnerabilities that don't rely on Mellon should still be reported).
  • Note: we are not interested in Open Redirect reports on Third Party Managed Websites unless they demonstrate an impact beyond phishing.
• Descriptive error messages (e.g. Stack Traces, application or server errors).
• HTTP 404 codes/pages or other HTTP non-200 codes/pages.
• Fingerprinting / banner disclosure on common/public services.
• Disclosure of known public files or directories, (e.g. robots.txt).
• Clickjacking and issues only exploitable through clickjacking.
• CSRF on forms that are available to anonymous users (e.g. the contact form).
• Logout Cross-Site Request Forgery (logout CSRF).
• Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.
• Lack of Secure/HTTPOnly flags on non-sensitive Cookies.
• Lack of Security Speedbump when leaving the site.
• Weak Captcha / Captcha Bypass
• Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.
• OPTIONS HTTP method enabled
• Username / email enumeration
  • via Login Page error message
  • via Forgot Password error message
• Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.
  • Strict-Transport-Security
  • X-Frame-Options
  • X-XSS-Protection
  • X-Content-Type-Options
  • Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP
  • Content-Security-Policy-Report-Only
• SSL Issues, e.g.
  • SSL Attacks such as BEAST, BREACH, Renegotiation attack
  • SSL Forward secrecy not enabled
  • SSL weak / insecure cipher suites
• Content spoofing / text injection without HTML/CSS
• Weak password policies
• Mail configuration issues including SPF, DKIM, DMARC settings
• Host header injection without exploitation
• DNSSEC configuration
• Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them
• Reports on Spotify's AI products or AI-enabled product features that do not demonstrate a security concern, such as offensive language, explicit content, and other safety violations.
• Hijacking of public RSS feeds
• Authorization bypasses involving Spotify's TOTP implementation are internally known and improvements are being worked on. We will remove this statement once they are available publicly.

Out of Scope bugs for Android apps

• Shared links leaked through the system clipboard.
• Any URIs leaked because a malicious app has permission to view URIs opened
• Absence of certificate pinning
• Sensitive data in URLs/request bodies when protected by TLS
• User data stored unencrypted on external storage
• Lack of obfuscation
• oauth "app secret" hard-coded/recoverable in apk
• Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)
• Any kind of sensitive data stored in app private directory
• Lack of binary protection control in android app

Out of Scope bugs for iOS apps

• Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries
• Absence of certificate pinning
• Path disclosure in the binary
• User data stored unencrypted on the file system
• Lack of obfuscation
• Lack of jailbreak detection
• oauth "app secret" hard-coded/recoverable
• Crashes due to malformed URL Schemes
• Lack of binary protection (anti-debugging) controls
• Snapshot/Pasteboard leakage
• Runtime hacking exploits (exploits only possible in a jailbroken environment)

Disclosure Guidelines

HackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:

• Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party.
• Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.
• If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.

Ethical Code

When retesting, we expect researchers to provide best effort validation to ensure the mitigation implemented by the Spotify team is sufficient. Any regression or bypass of the fix must be submitted as a new report and referenced as a bypass or regression of report # as per the platform policy. Attempts to game the policy and resubmitting the same issue with a slight tweak that should have reasonably been caught in retesting will not be considered for additional bounty and will be closed as “Not Applicable” (-5 reputation).