I'm testing this application which is properly validating origin header on the sever side. However, if I add any domain and the expect domain as port, application still consider this valid.

Origin: https://random-domain.com:expected-domain.com

This is also valid.

Origin: https://random-domain.com?expected.domain.com

I'm doing all this from my intercepting proxy but in real world origin header can't have parameters, fragments or alphabetical ports (numeric ports are possible though)

Is there a solution for this? I'm looking for a solution to bypass this and send an arbitrary origin header value and still get successful response.

  • What is your question exactly? Is there a solution for what? What is the problem exactly?
    – Sjoerd
    Feb 9, 2021 at 10:38
  • Sorry, if I was unclear, just updated the post. I'm looking for a solution to bypass this and submit an arbitrary origin header value and still get successful request.
    – Jack
    Feb 9, 2021 at 10:45

1 Answer 1


If you're wondering whether the behaviour you described can be abused, I can think of at least one exploit (described by James Kettle, from PortSwigger) that can lead to the equivalent of stored XSS, but only under certain conditions:

  1. The value of the Origin request header gets reflected verbatim in the Access-Control-Allow-Origin response header can have security implications.
  2. There is some Web caching but no Vary: Origin in responses.

You could then craft a request with a malicious Access-Control-Allow-Origin value containing a carriage return,

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

which would result in a header injection in some browsers (IE),

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

That malicious response would get cached on the server side and delivered to subsequent visitors.

You must log in to answer this question.

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