<p>Based on <a href="https://github.com/istio/istio/issues/23757" rel="nofollow noreferrer">https://github.com/istio/istio/issues/23757</a> it's been quite some time now that I get no answer about it, so I realized that most likely I don't understand the internals and I need to shift the question in another diretion.</p>
<p>I have a case where vulnerability scan shows that we are vulnerable to custom origin domains. The expectation from the provider is to block request that don't match a predefined ORIGIN within a virtual service allowOrigin setting.
I am trying to send OPTIONS preflights or simple gets, but no matter what I do the mesh always returns <strong>200</strong>:</p>
<pre><code>curl -s -H &quot;Origin: http://fake&quot; --verbose http://192.168.223.10:31380/productpage | grep -i &quot;HTTP/1.1 200 OK&quot;
curl -s -H &quot;Origin: http://testit.com&quot; --verbose http://192.168.223.10:31380/productpage | grep -i &quot;HTTP/1.1 200 OK&quot;
curl -s -X OPTIONS -H &quot;Origin: http://testit.com&quot; --verbose http://192.168.223.10:31380/productpage | grep -i &quot;HTTP/1.1 200 OK&quot;
curl -s -X OPTIONS -H &quot;Origin: http://fake&quot; --verbose http://192.168.223.10:31380/productpage | grep -i &quot;HTTP/1.1 200 OK&quot;
</code></pre>
<p>Is this something that controls only client blocking (browser) and if so how am I supposed to test it with curl?</p>
<p>I know how to reject a origin like, but it will just return not found then:</p>
<pre><code>- uri:
    exact: /productpage
  headers:
    origin:
      regex: &quot;*test.com&quot;
</code></pre>

anVzdGFub3RoZXJodW1hbg
<p>There is an answer to this issue on <a href="https://github.com/istio/istio/issues/23757#issuecomment-670165587" rel="nofollow noreferrer">github</a>:</p>
<hr />
<p>Hi everyone. Testing CORS using curl can be a bit misleading. CORS is not enforced at the server side; it will not return a 4xx error for example. Instead, headers are returned back which are used by browsers to deny/accept. <a href="https://www.google.com/url?q=https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/cors.html?highlight%3Dcors&amp;sa=D&amp;usg=AFQjCNHe3PigScjzrJhzCHwqR_sanWb5rA" rel="nofollow noreferrer">https://www.envoyproxy.io/docs/envoy/latest/start/sandboxes/cors.html?highlight=cors</a> gives a good demo of this, and <a href="https://www.google.com/url?q=https://www.sohamkamani.com/blog/2016/12/21/web-security-cors/%23:%7E:text%3DCORS%2520isn%27t%2520actually%2520enforced,header%2520in%2520all%2520its%2520responses&amp;sa=D&amp;usg=AFQjCNEmy6-dHMqCnVa7ZJyA28iIWqjQKw" rel="nofollow noreferrer">https://www.sohamkamani.com/blog/2016/12/21/web-security-cors/#:~:text=CORS%20isn't%20actually%20enforced,header%20in%20all%20its%20responses</a>. is a good explanation.</p>
<p>So Istio's job here is simply to return these headers. I have added a test showing this works: <a href="https://www.google.com/url?q=https://github.com/istio/istio/pull/26231&amp;sa=D&amp;usg=AFQjCNF0tovkG_5bBxkD3wdKnLF7_h2oYw" rel="nofollow noreferrer">https://github.com/istio/istio/pull/26231</a></p>
