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.

Certain vulnerabilities with a working proof of concept on some of our Android mobile app(s) may qualify for an additional bounty through the Google Play Security Rewards Program. To see which apps and vulnerabilities may qualify for a bounty, please refer to the Google Play Security Rewards Program’s Scope and Vulnerability Criteria.

You can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.

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.

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.

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

• When experimenting, please only attack 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 without checking with us first. 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 support@spotify.com.

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

• 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

• Assets we don't own such as expired domains even if they are listed in scope.

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 is out of scope

• 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 is out of scope

• Lack of jailbreak detection is out of scope

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