Couple days ago “XSS mitigation for Partner Reports” change was announced https://developer.atlassian.com/changelog/#CHANGE-1496
There was no RFC for this change, no warnings that it will come and now it actually breaks partner systems feeding invalid data.
The motivation for this change is described as
The partner reports consist of user input fields that currently allow HTML/JavaScript code as their value. This poses a risk of potential XSS vulnerabilities in partner systems that utilize this data.
To address this concern, we have implemented an additional validation process for specific data within partner reports. This validation involves using a standard HTML escaper, which has replaced certain HTML entities with alternative values.
This is the wrong way how to solve potential XSS vulnerabilities. Databases should store the data in the original format. REST API should return data in the original format. HTML escaping should only be used when displaying data data in HTML pages.
The correct XSS defense philosophy is to escape or sanitize all user data when including them in HTML output. Now this new change results in double HTML escaping of certain characters (&, < and >) in partner systems as well as in Atlassian Marketplace.
If you go to Atlassian Marketplace partner reports / licenses and search for & you can find a lot of corrupted data. For example, you can see AT&amp;T instead of AT&T as a company name.
Atlassian – please revert this change as it is the wrong solution for XSS vulnerabilities and does not implement the recommended secure application development practices and it is a breaking change that corrupts Atlassian Marketplace data in partner systems.
Partners – please share your comments and “likes” if you want this change to be reverted as well.
I wholeheartedly agree with @raimonds.simanovskis. The responsibility for preventing XSS is for the system that displays the data. The system that stores / provides API access to the data should not assume that the data will be used for displaying it within HTML. You also do not truncate data and pad it with ellipsis in your database if it is too long. You store the original and adjust it only when displaying it in a place where this is applicable.
In addition to this being a very bad practice, Atlassian is also once again overstepping it’s boundaries as a reseller.
If you want to uphold the lie that you want Atlassian Marketplace Partners to have a direct relationship with customers and pretend that you are a mere reseller, you should give us access to raw data provided by customers. Otherwise you are interfering with a relationship you are so desperate to pretend exists.
At the very least, this double escaping should be fixed. But I also agree that it was fine how it was before. It is not Atlassian’s responsibility to escape all their APIs against potential XSS, there are plenty of examples in product APIs (e.g. Jira) where no data is escaped and it is the REST API user’s responsibility to do so.
Since these HTML vulnerabilities aren’t anything new, I’m wondering quite a bit why Atlassian isn’t using a proven mitigation approach to address them, but rather re-invents the wheel?
First and foremost, we would like to extend our sincere apologies for any inconvenience the change (XSS mitigation in transactions report) may have caused. The primary motivation (based on partner request) behind this alteration was to safeguard against potential XSS attacks, recognizing that not all of our partners utilizing our APIs are equipped with an XSS defence mechanism on their end. Having said that, we recognize the impact of this decision on some of our partners (who are mitigating at their end) and have decided to roll back this change. We will reevaluate our approach and explore a more agreeable solution.