I found a website that has a well implemented CORS configuration, but for some reason I am able to insert two Origin headers in a POST request, and both of these values are reflected in the reponse.

So if I try:

Host: example.com
Connection: close
Origin: https://evil.com
Origin: https://example.com

The response will be:

HTTP/1.1 200 OK

access-control-allow-origin: https://evil.com,https://example.com
access-control-allow-credentials: true

Is there any way to set this in a payload to be able to exploit this? How could I set the origin value for both of this to exploit it?

  • A possible explanation for this behaviour: The server is implemented in Javascript and represents request headers as an object with the values being either strings (for single headers) or arrays of strings (for headers appearing multiple times). Note that Javascript stringifys arrays by joining the elements with commas: String(["a","b"]) == "a,b" Nov 15, 2019 at 9:44

2 Answers 2


First of all, to be clear: A site that returns ACAO: {your origin} for arbitrary origins, and also returns ACAC: true, is completely insecure. That site has, for the most part, turned off the same-origin policy's protections for itself; any other site on the Internet is able to view the content of, and take control of, any user's session on the vulnerable site. If you're content with client-side attacks (the category that contains XSS, CSRF, clickjacking, etc.), a site configured the way you describe is wide open. You don't need double origins or anything like that.

Now, as for whether you can do anything interesting with the bizarre behavior the server displays when you send two Origin headers: I don't know. Assuming you can control the Origin header somehow - which isn't supposed to be possible from within a browser, and is easy from something like curl but non-browser clients don't have same-origin policy and thus don't require CORS anyhow - you can try to break the server's processing of the headers. Standard attacks include newlines in the header (using %09/%0D or other encodings) to see if you can inject additional headers or entire body responses, null bytes to try confusing string-parsing code, large numbers of keys that all hash to the same value (using the platform's hashCode implementation) to try overloading a hashtable and causing a DoS attack, and more. Most of those aren't in any way particular to either the Origin header or the behavior you're observing, though.


I don't think this is exploitable.

If you want your server to allow any origin (this might not be the safest setup, but anyways), a common way to do that is to simply echo back whatever the client sends as Origin in Access-Control-Allow-Origin. I guess that is what is happening here.

How are you setting two origins? I assume that it is not the browser that sets two of them. If you manipilate the Origin header outside of the browser, it is easy to break CORS in all sorts of ways. But the whole purpose of CORS is to configure the same origin policy, which is a thing maintained by the browser. It is completely expected and normal that CORS can be broken if you use a client that doesn't play along.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .