Skip to content
bugbounty.fyi
Get paid to secure open source 475 paid open-source programs on Sorona, up to $1M Perk Low bugs: $100 or 1 mo Claude Max

Also on Patchstack. All 476 paid open-source programs

Try

Highest paying Newly launched Paid without KYC Full safe harbor
All results

About this site

Spotify

Bug bounty on HackerOne spotify.com

Accepting reports
Go to program Website
Top reward
$8,000
Top severity paid
Critical
Assets in scope
45
Public CVEs
2
Last change
No changes yet

At a glance

What to know before you start testing.

Pays up to $8,000
for critical bugs.
Report on HackerOne
Submit through the program page.
Partial safe harbor
Some legal protection; read the terms.
No public write-ups
Keep findings private.

Rewards

What HackerOne lists as the payout for each severity.

Severity Reward
Critical $8,000
High $4,000
Medium $700
Low $500
Safe harbor
Partial 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.

Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original

Scope

45 assets you may test, 9 excluded.

Wildcard domains 10

  • *.atspotify.com Low
  • *.avecspotify.com Low
  • *.byspotify.com Low
  • *.enspotify.com Low
  • *.forspotify.com Low
  • *.fromspotify.com Low
  • *.spotify.com Critical
  • *.spotify.net Critical
  • *.tospotify.com Low
  • *.withspotify.com Low

Source code 6

  • Android SDK Critical
  • Core Backstage source code Critical
  • https://github.com/backstage/backstage Medium
  • iOS SDK Critical
  • Spotify SDKs Critical
  • Web Playback SDK Critical

Android apps 5

  • com.spotify.kids Critical
  • com.spotify.music Critical
  • com.spotify.s4a Critical
  • com.spotify.tv.android Critical
  • fm.anchor.android Critical

iOS apps 4

  • com.anchorfminc.Anchor Critical
  • com.spotify.client Critical
  • com.spotify.kids Critical
  • com.spotify.s4a Critical

Web 4

  • api.spotify.com Critical
  • assets.spotify.com Critical
  • backstage.io Medium
  • https://www.whosampled.com Critical

Desktop and binaries 2

  • Save to Spotify CLI Critical
  • Spotify desktop application (Windows and Mac) Critical

APIs 1

  • api-partner.spotify.com Critical

Products and areas 13

  • Anchor Critical
  • Core Assets Critical
  • DRM (Digital Rights Management) System Critical
  • GHE Critical
  • Jira Critical
  • Megaphone Critical
  • Non-Core Assets Critical
  • Okta Critical
  • Other Spotify websites Critical
  • Podsights Critical
  • Sonantic Critical
  • VPN Critical
  • Wrapped Critical
Out of scope (9)
  • com.soundtrap.studioapp
  • com.soundtrap.studioapp
  • Confidence Domains
  • Findaway
  • Preact
  • Soundtrap
  • The Ringer
  • everynoise.com
  • example.com

Rules

What the policy asks of you, and the bug types it won't reward, quoted from Spotify (via HackerOne)'s policy. "We" in these lines means the program, not this site.

While testing

  • When experimenting, please only target accounts belonging to you.
  • Do not run automated scans.
  • 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.
  • Unless Spotify gives you permission, do not disclose any issues, personal data or any other confidential info to the public, or to any third party.
  • Researchers may test the validity of credentials solely to the extent of confirming authentication, followed by immediate deauthentication

Not accepted

  • Reports of compromised accounts, accounts exposed in data breaches, or publicly accessible password dumps
  • Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect
  • 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
  • Missing HTTP security headers
  • SSL Issues
  • 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
  • Hijacking of public RSS feeds

Summarised with AI from the program policy on HackerOne, read 12 Nov 2026, and checked word for word against it. Read the original

Changes

Tracked since 11 Nov 2026. Last checked 1 hour ago.

No changes yet. When the rewards or scope move, you will see it here and in the RSS feed.

Public CVEs

Published vulnerabilities in this vendor's products, from the NVD.

Search NVD
CVESeverityPublished
CVE-2018-1000843 High 8.8 20 Dec 2018
CVE-2018-1167 High 8.8 19 Apr 2018

Original policy

Copied from hackerone.com on 12 Nov 2026. The summaries on this page are made from it; the live page may have changed since.

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:

Severity Vulnerability
Critical Remote code execution used to exfiltrate sensitive Spotify customer data OR SQL Injection that leads to exposure of sensitive information like Spotify customer phone numbers, home addresses, or payment information.
High Authentication bypass that allows a user to authenticate and escalate privileges without proper credentials, SSRF that reveals authorization credentials or content available in configuration files, OR Denial of Service that will disrupt the playback experience.
Medium Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate.

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. See Scope for the version requirements. For issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.

Note on UUID's While we understand that UUID's obfuscate and do not protect data, we consider access control vulnerabilities that rely on UUID's to be too low of a risk due to the entropy of such ID's. Examples of reports we do accept in this space include:

  1. Poorly generated ID's that are easily predictable
  2. UUID's that are enumerated elsewhere in the Spotify platform and accessible publicly in bulk, which can then be used to bypass access controls (e.g. via an IDOR)

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, personal data or any other confidential info 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).