The way the Square API delivers JSON output makes it possible for attackers to engage in a cross-site scripting (XSS) under certain circumstances. The vulnerability was discovered by security researcher Ajay Chavda and reported to Square on August 7, 2015 through its bug bounty program on HackerOne. He says it was triaged on August 12, but it wasn't until October 2 that Chavda received a response from Square indicating that "After extensive discussion, we have decided not to implement a fix for this at this time."
On October 8, Chavda requested a public disclosure and never received a response. Six months later he published information about the vulnerability on his blog. Square did not respond to a ProgrammableWeb request for comment.
Chavda told me that he had previously reported issues to Square through the hackerone program and received rewards for his reports. During his testing of the Square API he discovered that the API does not escape its JSON output, which could allow for XSS attacks when a consuming application does not safeguard its output.
As Chavda explained, although Square's output uses the application/json content type, if a partner application uses Square API's output and serves it with content of the type text/html, an XSS attack becomes possible.
Most worryingly, the threat of this occurring is not hypothetical. During his research, Chavda discovered a Square app by Stitch Labs that is vulnerable. As seen in the screenshot below provided by Chavda, demonstrating the vulnerability requires nothing more than changing the name on a Square account to something like >'>"><img src=x onerror=alert(0)> and then authorizing the Stich Labs app.
Chavda reported this to Stitch Labs in September, and it was acknowledged, but it appeared to not be addressed. ProgrammableWeb was recently notified that Stitch Labs addressed this issue although the timeline is unclear. Chavda also brought the Stitch Labs app to Square's attention, but the app is still available through Square's App tab despite the fact that it remains vulnerable.
A Question of Responsibility
Before submitting his discovery to Square, Chavda pondered who should be responsible for "safeguarding and properly escaping the JSON outputs." Indeed, there is an argument to be made that developers, and not the API provider, are ultimately responsible, but Chavda says that Square's slow and tepid response was "discouraging."
More importantly, the app he discovered is available to all Square customers via the Apps tab in their account, so even if one concludes that Square can't ensure developers output data from its API in a safe fashion, it's not unreasonable to expect that Square would screen the third-party apps it promotes to its customers and take action when one is found to be vulnerable.
Put simply, while API providers have every right to ask that developers adhere to certain practices, they also need to be prepared to step in when those practices aren't followed so that end users aren't unnecessarily left vulnerable to malicious attacks.