There actually isn't any problem here, as all these sites are just as vulnerable to direct attacks irrelevant of the XSS headers. XSS only protects users which load data from suspicious websites, and those websites intend to make malicious calls to the vulnerable ones. Oh, did I mentioned the user has to be still logged in. This is nothing new, and why most browser default configuration is to prevent XSS. As a matter of fact XSS is required for all those social media APIs little icons to actually function, it isn't a vulnerability, it's a feature, and a useful one at that.

This is definitely the best post so far. Sending out requirements to different vendors will just get you a vender specific answer. If you ask a DBA how to store that much data they will give you an answer that explains how MSSQL could handle that, and then they would talk about backup snashots, and you would be stuck with SQL as the client access.

I want to reject the premise of your request, are you really responsible for manging the data of these two other groups? It seems like in the past you have owned the storage for other internal teams, but now the time has come for them to start doing this themselves. Option 1, you own the service that does this, you don't pay attention do limits and anything like that, and provide an SLA to groups that want to use your service. This has probably been what you currently doing. Some teams may be unhappy with that service because it doesn't quite fit their needs. Option 2, each team that wants something different and should manage it themselves. Where an filesystem for one team may be what they need, perhaps a different team wants MongoDB shards.

Monoliths are evil, and trying to maintain petabytes of data in one place is not a good solution. It's easier for two teams to maintain and own their own Terabyte storage solutions that will solve their own problems, then having you to try to mediate and come up with the solution yourself.