[{"id":3764342,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe'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.\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:\n* playplay DRM system vulnerabilities on mobile client versions 9.0.0+\n* playplay DRM system vulnerabilities on desktop client versions 1.2.53+\n\nFor issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n    * Note: we are not interested in Open Redirect reports on Third Party Managed Websites unless they demonstrate an impact beyond phishing.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n* 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.\n* Hijacking of public RSS feeds\n* 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.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-10-08T15:52:39.096Z"},{"id":3762983,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe'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.\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:\n* playplay DRM system vulnerabilities on mobile client versions 9.0.0+\n* playplay DRM system vulnerabilities on desktop client versions 1.2.53+\n\nFor issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n    * Note: we are not interested in Open Redirect reports on Third Party Managed Websites unless they demonstrate an impact beyond phishing.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n* 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.\n* Hijacking of public RSS feeds\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-09-18T17:31:28.193Z"},{"id":3757614,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe'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.\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:\n* playplay DRM system vulnerabilities on mobile client versions 9.0.0+\n* playplay DRM system vulnerabilities on desktop client versions 1.2.53+\n\nFor issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n    * Note: we are not interested in Open Redirect reports on Third Party Managed Websites unless they demonstrate an impact beyond phishing.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n* 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.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-06-16T17:30:15.508Z"},{"id":3752341,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:\n* playplay DRM system vulnerabilities on mobile client versions 9.0.0+\n* playplay DRM system vulnerabilities on desktop client versions 1.2.53+\n\nFor issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n    * Note: we are not interested in Open Redirect reports on Third Party Managed Websites unless they demonstrate an impact beyond phishing.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-03-25T14:46:35.539Z"},{"id":3751308,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate a vulnerability in Spotify’s implementation and meet these requirements:\n* playplay DRM system vulnerabilities on mobile client versions 9.0.0+\n* playplay DRM system vulnerabilities on desktop client versions 1.2.53+\n\nFor issues with DRM systems/vendors that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-03-06T16:07:44.786Z"},{"id":3748944,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\nWe encourage researchers to report leaked credentials pertaining to our corporate/internal assets, such as ==\u003cspotify.okta.com\u003e==, while adhering to the guidelines outlined below:\n\n* 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.\n* 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).\n* 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.\n* 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.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2025-01-28T15:45:54.087Z"},{"id":3747195,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-12-27T14:16:19.158Z"},{"id":3745337,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-11-27T14:12:30.546Z"},{"id":3737727,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\nWe 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. \n\nWe are particularly interested in the following categories of security bugs on our core-assets:\n\n| Severity | Vulnerability |\n|-----|-----|\n| 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. |\n| 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. |\n| Medium | Broken authentication and session management that are performed via unencrypted connections or the session does not properly terminate. |\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-09-03T17:34:28.042Z"},{"id":3735426,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* 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).\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation\n* Lack of jailbreak detection\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n## Ethical Code\n\nWhen 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).\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-08-07T17:08:52.021Z"},{"id":3734862,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\nWe accept research on DRM issues that demonstrate vulnerability in Spotify’s implementation. For issues with DRM systems that Spotify uses, please see the section on Third Party Dependencies.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-08-01T12:43:52.184Z"},{"id":3726340,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n* Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-16T13:52:45.782Z"},{"id":3726339,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n*Vulnerabilities that utilize unique IDs (e.g. UUIDs) without the demonstration of an effective enumeration technique to obtain them\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-05-16T13:49:42.309Z"},{"id":3713841,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details under the Scope tab. **Unless specified on the scope page, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third Party Dependencies\n \nA 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. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\n##Third Party Managed Websites\n\nPlease 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:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nThere can be third party assets under various domains not listed here and we ask for your patience as we determine their status.\n\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-08T14:11:06.707Z"},{"id":3713710,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\nPlease note that there is a multitude of 3rd party managed sites under the Spotify name. If a bug you have submitted is managed by a 3rd party we will award you a $100 bonus BUT close the report as informational. 3rd party sites include but are not limited to:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nDomains that will most likely not fall under a 3rd party, but are still bounty-eligible:\n- Chartable\n- Podsights\n- Anchor\n- Heardle\n- Findaway\n- Backstage\n- Gimlet\n- Loudr\n- Megaphone\n- Niland\n- The Ringer\n- Whooshkaa\n- Parcast\n- Preact\n\nThere are other sites such as *.spotify.com that could be internal or 3rd party, and we ask for your patience as we determine their 3rd party status.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-06T16:30:31.812Z"},{"id":3713650,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\nPlease note that there is a multitude of 3rd party managed sites under the Spotify name. If a bug you have submitted is managed by a 3rd party we will award you a $100 bonus BUT close the report as informational. 3rd party sites include but are not limited to:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nDomains that will most likely not fall under a 3rd party, but are still bounty-eligible:\n- Chartable\n- Podsights\n- Anchor\n- Heardle\n- Findaway\n- Soundtrap\n- Backstage\n- Gimlet\n- Loudr\n- Megaphone\n- Niland\n- The Ringer\n- Whooshkaa\n- Parcast\n- Preact\n\nThere are other sites such as *.spotify.com that could be internal or 3rd party, and we ask for your patience as we determine their 3rd party status.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-03-05T19:10:55.863Z"},{"id":3710382,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\nPlease note that there is a multitude of 3rd party managed sites under the Spotify name. If a bug you have submitted is managed by a 3rd party we will award you a $100 bonus BUT close the report as informational. 3rd party sites include but are not limited to:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nDomains that will most likely not fall under a 3rd party:\n- Chartable\n- Podsights\n- Anchor\n- Heardle\n- Findaway\n- Soundtrap\n- Backstage\n- Gimlet\n- Loudr\n- Megaphone\n- Niland\n- The Ringer\n- Whooshkaa\n- Parcast\n- Preact\n\nThere are other sites such as *.spotify.com that could be internal or 3rd party, and we ask for your patience as we determine their 3rd party status.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2024-01-08T16:22:48.903Z"},{"id":3708834,"new_policy":"**Update from Spotify (Friday Dec. 8, 2023)**\n\nHi All,\n\nDue to unforeseen circumstances, we have made the decision to temporarily realign our Bug Bounty program and only accept High and Critical-severity submissions for the remainder of this year. Any valid reports submitted before this communication will still be paid out.\n\nWe apologize in advance, but want to ensure we are providing the best experience possible and will reconsider bounty eligibility in the new year. Thank you for all your efforts and patience.\n\nThanks,\nSpotify Team\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\nPlease note that there is a multitude of 3rd party managed sites under the Spotify name. If a bug you have submitted is managed by a 3rd party we will award you a $100 bonus BUT close the report as informational. 3rd party sites include but are not limited to:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nDomains that will most likely not fall under a 3rd party:\n- Chartable\n- Podsights\n- Anchor\n- Heardle\n- Findaway\n- Soundtrap\n- Backstage\n- Gimlet\n- Loudr\n- Megaphone\n- Niland\n- The Ringer\n- Whooshkaa\n- Parcast\n- Preact\n\nThere are other sites such as *.spotify.com that could be internal or 3rd party, and we ask for your patience as we determine their 3rd party status.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-12-08T19:43:46.975Z"},{"id":3686061,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\nPlease 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.\n\nPlease note that there is a multitude of 3rd party managed sites under the Spotify name. If a bug you have submitted is managed by a 3rd party we will award you a $100 bonus BUT close the report as informational. 3rd party sites include but are not limited to:\n- *.withspotify.com\n- *.byspotify.com\n- *.atspotify.com\n\nDomains that will most likely not fall under a 3rd party:\n- Chartable\n- Podsights\n- Anchor\n- Heardle\n- Findaway\n- Soundtrap\n- Backstage\n- Gimlet\n- Loudr\n- Megaphone\n- Niland\n- The Ringer\n- Whooshkaa\n- Parcast\n- Preact\n\nThere are other sites such as *.spotify.com that could be internal or 3rd party, and we ask for your patience as we determine their 3rd party status.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-04-12T14:03:14.054Z"},{"id":3684693,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n##Third-party Dependencies\n \nA 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 agree that 3rd-party code authors should have the advantage of learning about the vulnerabilities within their code first. \n\nSubmissions of vulnerabilities through 3rd-party dependencies should:\n* Demonstrate that the vulnerability manifests within our projects. Meaning you must be able to show that the vulnerability can be exploited within Spotify applications.\n* 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).\n* 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2023-03-14T03:40:29.539Z"},{"id":3664789,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2022-01-24T18:11:14.260Z"},{"id":3660158,"new_policy":"## Note for researchers submitting reports between October 30th - November 7th: Please expect delays in Spotify's response for low and medium vulnerabilities reported from October 30th - November 7th.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-10-18T15:42:01.940Z"},{"id":3657916,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Absence of brute force countermeasures (e.g. rate limiting, account lockout), unless a successful attack can be demonstrated.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-09-06T10:02:32.974Z"},{"id":3656269,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* Assets we don't own such as expired domains even if they are listed in scope.\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-08-05T18:14:39.186Z"},{"id":3654283,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* **Do not run automated scans without checking with us first.** They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-07-06T13:26:06.786Z"},{"id":3652608,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n***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.***\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2021-05-21T18:20:09.165Z"},{"id":3641966,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-09-02T16:33:34.678Z"},{"id":3635230,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-04-20T16:15:32.549Z"},{"id":3631762,"new_policy":"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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. **Unless specified, companies acquired by Spotify are not in scope.**\n\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* 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.\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n* Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-02-27T22:00:38.099Z"},{"id":3627848,"new_policy":"#Policy\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Open redirect vulnerabilities which use a Spotify subdomain and the /mellon/logout URL to implement a redirect\n    * Other redirect vulnerabilities that *don't* rely on Mellon should still be reported.\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n    * via Login Page error message\n    * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2020-01-09T21:18:04.685Z"},{"id":3620968,"new_policy":"#Policy\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-10-10T17:22:38.007Z"},{"id":3618035,"new_policy":"#Recent news\n## 2019-5-14\nWe have added assets for Gimlet Media into scope for our Bug Bounty Program. Spotify acquired Gimlet Media in February 2019. Sites in the *.gimletmedia.com domain are now eligible for our Bug Bounty Program.\n\n#Policy\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* DNSSEC configuration\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-09-04T11:52:11.444Z"},{"id":3611890,"new_policy":"#Recent news\n## 2019-5-14\nWe have added assets for Gimlet Media into scope for our Bug Bounty Program. Spotify acquired Gimlet Media in February 2019. Sites in the *.gimletmedia.com domain are now eligible for our Bug Bounty Program.\n\n#Policy\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* 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.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-06-14T08:31:56.614Z"},{"id":3609444,"new_policy":"#Recent news\n## 2019-5-14\nWe have added assets for Gimlet Media into scope for our Bug Bounty Program. Spotify acquired Gimlet Media in February 2019. Sites in the *.gimletmedia.com domain are now eligible for our Bug Bounty Program.\n\n## 2019-5-13\nWe have two promotions scheduled for the Spotify Bug Bounty Program:\n\n* The first will run from May 13 until Midnight May 26. It is valid for all targets in scope for Spotify and has a reward multiplier for higher severity vulnerabilities. Earn up to 50% extra during this promotion!\n* The second will run from May 31 - July 1. To be eligible for promotion, reported vulnerabilities must require Spotify Premium. Earn up to 50% extra during this promotion!\n\n#Policy\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-05-14T16:11:00.657Z"},{"id":3608307,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\n\nTo 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.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nCertain 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](https://hackerone.com/googleplay). 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-04-26T17:36:48.212Z"},{"id":3603967,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\nWe 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.\n\nYou can find more details in the Structured Scope Section below. Unless specified, companies acquired by Spotify are not in scope.\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2019-03-01T14:59:07.281Z"},{"id":3568385,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*Soundtrap web site \u0026 API (https://www.soundtrap.com)*\n\n*All other companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2018-02-06T08:28:47.517Z"},{"id":3555822,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*All companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable \n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-16T15:04:06.480Z"},{"id":3555410,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*All companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* Content spoofing / text injection without HTML/CSS\n* Weak password policies\n* Mail configuration issues including SPF, DKIM, DMARC settings\n* Host header injection without exploitation\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-06-09T15:03:27.850Z"},{"id":3554751,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*All companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-05-31T17:26:22.500Z"},{"id":3554750,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*All companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n\n# Hello, researcher!\n\nWe'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.\n\nSo, needless to say, we take security issues very seriously.\n\n##Your Spotify account\nFor **password and login problems**, if you think your account has been “**stolen**”, or other issues with your Spotify account, please contact us using our [contact form](https://support.spotify.com/us/problems/#!/article/Problems-logging-in-to-Spotify/).\n\n##Spotting major security issues\nIf you have discovered a vulnerability in Spotify or another serious **security issue**, please contact our dedicated email support security@spotify.com\n\n## Vulnerability rewards\n### Compensation\nWe are happy to receive good reports on security issues, and may sometimes reward good reports with **monetary rewards**, and/or **swag**. Please note that we do so at our sole discretion, any decisions on **rewards are our decision**.\n\nOur monetary rewards, starting from $250, are based on the **severity** of the reported issue and the **quality of the report**. To help you know what to expect, we include some guidelines below. Please understand that we cannot provide an exhaustive list on exactly what will or will not qualify for a reward.\n\n###Responsible disclosure\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-05-31T17:19:31.325Z"},{"id":3554748,"new_policy":"# PLEASE NOTE: Submissions will not be paid until they have been fixed and moved to the ‘Resolved’ state.\n\nWe'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.\nSo, needless to say, we take security issues **very** seriously.\n\nIn 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.\n\nResponsible disclosure is the **industry best practice**, and we recommend it as a procedure to anyone researching security vulnerabilities.\n\n### Rules of engagement\nWe are interested in hearing about security issues on all Spotify properties, including our client software, SDKs and web services hosted domains owned by Spotify.\nTo 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, just provide the information you have, and we will analyze your report and draw conclusions on the impact.\n\n### There are some things we explicitly ask you not to do:\n\n* When experimenting, please only attack test accounts you control. A PoC unnecessarily involving accounts of other end users or Spotify employee may be disqualified.\n* Do not run automated scans without checking with us first. They are often very noisy.\n* Do not test the physical security of Spotify offices, employees, equipment, et.c.\n* Do not test using social engineering techniques (phishing, vishing, et.c.)\n* Do not perform DoS or DDoS attacks.\n* In any way attack our end users, or engage in trade of stolen user credentials.\n\n## Targets\n\n### In scope\n* Spotify SDKs\n* Spotify APIs\n* All Spotify Clients (Web \u0026 Mobile)\n* All Spotify Websites\n\n*Spotify for iOS: https://itunes.apple.com/us/app/spotify-music/id324684580?mt=8*\n*Spotify for Android: https://play.google.com/store/apps/details?id=com.spotify.music\u0026hl=en*\n\n*All companies acquired by Spotify are not in scope.*\n\n**The following finding types are specifically excluded from the bounty:**\n\n* Descriptive error messages (e.g. Stack Traces, application or server errors).\n* HTTP 404 codes/pages or other HTTP non-200 codes/pages.\n* Fingerprinting / banner disclosure on common/public services.\n* Disclosure of known public files or directories, (e.g. robots.txt).\n* Clickjacking and issues only exploitable through clickjacking.\n* CSRF on forms that are available to anonymous users (e.g. the contact form).\n* Logout Cross-Site Request Forgery (logout CSRF).\n* Presence of application or web browser ‘autocomplete’ or ‘save password’ functionality.\n* Lack of Secure/HTTPOnly flags on non-sensitive Cookies.\n* Lack of Security Speedbump when leaving the site.\n* Weak Captcha / Captcha Bypass\n* Forgot Password page brute force and account lockout not enforced.\n* OPTIONS HTTP method enabled\n* Username / email enumeration\n  * via Login Page error message\n  * via Forgot Password error message\n* Missing HTTP security headers, specifically (https://www.owasp.org/index.php/List_of_useful_HTTP_headers), e.g.\n  * Strict-Transport-Security\n  * X-Frame-Options\n  * X-XSS-Protection\n  * X-Content-Type-Options\n  * Content-Security-Policy, X-Content-Security-Policy, X-WebKit-CSP\n  * Content-Security-Policy-Report-Only\n* SSL Issues, e.g.\n  * SSL Attacks such as BEAST, BREACH, Renegotiation attack\n  * SSL Forward secrecy not enabled\n  * SSL weak / insecure cipher suites\n* assets.spotify.com is excluded from the program\n\n**Out of Scope bugs for Android apps**\n* Shared links leaked through the system clipboard.\n* Any URIs leaked because a malicious app has permission to view URIs opened\n* Absence of certificate pinning\n* Sensitive data in URLs/request bodies when protected by TLS\n* User data stored unencrypted on external storage\n* Lack of obfuscation is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed Intents sent to exported Activity/Service/BroadcastReceive (exploiting these for sensitive data leakage is commonly in scope)\n* Any kind of sensitive data stored in app private directory\n* Lack of binary protection control in android app\n\n**Out of Scope bugs for iOS apps**\n* Lack of Exploit mitigations ie PIE, ARC, or Stack Canaries\n* Absence of certificate pinning\n* Path disclosure in the binary\n* User data stored unencrypted on the file system\n* Lack of obfuscation is out of scope\n* Lack of jailbreak detection is out of scope\n* oauth \"app secret\" hard-coded/recoverable in apk\n* Crashes due to malformed URL Schemes\n* Lack of binary protection (anti-debugging) controls\n* Snapshot/Pasteboard leakage\n* Runtime hacking exploits (exploits only possible in a jailbroken environment)\n\n## Disclosure Guidelines\n\nHackerOne's Disclosure Guidelines shall not apply when participating in a Spotify program. Instead, we ask you to abide by the following Spotify Disclosure Guidelines:\n\n* Unless Spotify gives you permission, do not disclose any issues to the public, or to any third party. \n* Unless Spotify gives you permission, do not disclose any report submitted in relation to a Spotify program.\n* If you have questions on timelines (to remediation, to bounty, etc.), please ask directly in the relevant report.\n","has_open_scope":null,"pays_within_one_month":null,"protected_by_gold_standard_safe_harbor":null,"protected_by_ai_safe_harbor":null,"disclosure_declaration":null,"introduction":null,"platform_standards_exclusions":[],"exemplary_standards_exclusions":[],"scope_exclusions":[],"timestamp":"2017-05-31T16:50:46.189Z"}]