I was testing a website and noticed that changing the "Origin" Header's value of a request with an intercepting proxy application results in the web application sending a response with "Access Control Allow Origin" set to the same changed value. I read that the Origin header is protected by the browser and cannot be changed. I want to know if there can be any potential risk associated with this scenario.

  • This is exactly how you would expect a public API to behave. If the API is supposed to be public this is by design, if not it might be a vulnerability.
    – Anders
    Commented Oct 13, 2017 at 9:25
  • @Anders Where has the OP mentioned that it is a public API?
    – Shurmajee
    Commented Oct 13, 2017 at 9:32
  • 1
    @Shurmajee He hasn't mentioned it. I am just saying that this is the behaviour you would expect from one.
    – Anders
    Commented Oct 13, 2017 at 9:35

2 Answers 2


If the server simply mirrors the Origin provided by the client into the Access-Control-Allow-Origin header of the response without further checks then it essentially allows any third party to access the resource cross-origin, i.e. it would be a security issue if cross-origin access should be restricted.

But, if this mirroring is only done after additional checks, for example only if the client is authorized, then this is less of a problem. Although there might also be cases where it can be a problem also in this case.

In summary: if this is a problem or not depends on information which are not provided in the question.


The vulnerability that you have noticed is called CORS mis-configuration. There is a good blog post by PortSwigger (Guys behind Burp suite) which talks about the same topic.

Before we go ahead and try to answer this question, I think a few dots need to be connected.

The Basics

The same-origin policy (SOP) is a browser-level security control that dictates how a document or script belonging to one origin can interact with a resource from some other origin. Basically, SOP prevents scripts running under one origin from reading data from another origin. There may be cases where an app needs to allow other origins for resource access. This is achieved by using Cross Origin Resource Sharing. There can be potential security issues due to CORS mis-configurations.

The Problem

Now, We understand that CORS can be used to allow cross origin data access in a controlled manner using Access-Control headers. However there is a problem. The Access-Control-Allow-Origin header works fine if you need to trust only one third party domain with data access. However, there may be cases where a white-list of domains need to be provided cross domain access. This is where the problem lies. None of the browsers support specifying multiple origins in the Access-Control header. You can not even cover sub-domains using wildcards e.g.

Access-Control-Allow-Origin: abc.com xyz.com (NOT SUPPORTED)

Access-Control-Allow-Origin: *.example.com (NOT SUPPORTED)

This has forced many developers to use the origin header value form the HTTP request and dynamically generate the Access-Control-Allow-Origin header to provide required access. Basically the Origin header value sent in the request is reflected back in the Access-Control-Allow-Origin reponse header (For a detailed explanation, refer to the blog post above)

This behavior violates one of the basic principles of security:

All data coming from the client should be treated as untrusted until validated.

The Vulnerability

This behavior basically defeats the purpose of Same-Origin-Policy. As the Access-Control-Allow-Origin header can be controlled by the client, Any malicious domain can now request data from the target web application and read the response. The only condition being that the targeted user should have the target site and the malicious site opened in the same browser at the same time along with an authenticated session with the target site. This provides unlimited access to the malicious site allowing it to perform all kinds of user actions and capture user data.

This is a tricky vulnerability to fix and unless the browsers start providing better support to the CORS white-listing options, We need to programmatically validate the requesting domain before allowing cross origin access.

  • I think you are misunderstanding the issue, or I am misunderstanding your answer. You say that data from the client can not be trusted. That is correct. But we can trust the browser to enforce the SOP. Using the origin header to determine if access should be allowed or not is totally fine, it is exactly what the spec recommends you to do. You seem to suggest that there is some fundamental flaw in CORS itself, but there is not.
    – Anders
    Commented Oct 13, 2017 at 9:30
  • @Anders I do not intend to mean that CORS is flawed :) . The behavior mentioned by the OP indicates that the application takes the Origin header from the request and puts the value in the Access-Control response header i.e. the user supplied value is reflected back in the HTTP response. This is where I mention that the Origin value from the HTTP request should not be blindly trusted and used in the Access-Control header. I have tried to clarify the same in my recent edit.
    – Shurmajee
    Commented Oct 13, 2017 at 9:39
  • Ah, I understand better now. I don't think spoofed origin headers are a problem, but I do agree that you need to be careful to implement the whitelisting correctly.
    – Anders
    Commented Oct 13, 2017 at 13:07
  • @Anders I think I need to clarify a little more. I am not talking about origin header spoofing here. Its just malicious sites sending sending cross domain requests. Imagine a CSRF attack where you can read data from the target domain because of a CORS misconfiguration.
    – Shurmajee
    Commented Oct 13, 2017 at 16:57

You must log in to answer this question.

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