On the contrary, that's precisely the vulnerability: 1. The API server needs authentication, which gets cached in the user-agent. 2. The same user-agent, with

On the contrary, that's precisely the vulnerability: 1. The API server needs authentication, which gets cached in the user-agent. 2. The same user-agent, with the same authentication context, is then directed to a malicious site. 3. The user-agent contains a javascript interpreter, and the malicious website serves a script to override the Array prototype. 4. The same script then executes a CSRF request to the API server, reusing the cached authentication context, and therefore stealing the response. A browser fits all the necessary conditions that must exist for this vulnerability to be exploited, but if you're the consumer of the API, you don't have to use a browser as your user-agent. You can write your own, which you'd do if you're making these requests programmatically in a non-web application. Regardless as to which user-agent you use, a viable mitigation is to not visit untrusted endpoints with the same cookie jar or authentication context. Another viable mitigation is to omit including a script interpreter in your custom API client. This is in fact usually the case.