<p>We are using Kubernetes with Istio and have configured a virtual service:</p>
<pre><code>  http:
  - match:
    - uri:
        prefix: /api
    rewrite:
      uri: /api
    route:
    - destination:
        host: svc-api
        port:
          number: 80
        subset: stable
      weight: 0
    - destination:
        host: svc-api
        port:
          number: 80
        subset: vnext
      weight: 100
    corsPolicy: &amp;apiCorsPolicy
      allowOrigins:
      - exact: '*'
      allowMethods:
      - GET
      - POST
      - OPTIONS
      allowCredentials: true
      allowHeaders:
      - &quot;*&quot;
  - match:
    - uri:
        prefix: /
    rewrite:
      uri: /
    route:
    - destination:
        host: svc-api
        port:
          number: 80
        subset: stable
      weight: 0
    - destination:
        host: svc-api
        port:
          number: 80
        subset: vnext
      weight: 100
    corsPolicy: *apiCorsPolicy
</code></pre>
<p>Making a request to <code>https://[host]/api/*</code> from a browser fails on OPTIONS request with <code>'from origin [request] has been blocked by CORS policy'</code>.</p>
<p>Describing the service in k8 shows the correct configurations.</p>
<p>According to v 1.6.4 the structure using <code>allowOrigins</code> and <code>exact</code> instead of <code>allowOrigin</code> is correct.</p>
<p>What am I missing here?</p>

Casper Nybroe
<p>Few things worth to mention here.</p>
<hr />
<p>Recently in older istio versions there were a problem with cors and jwt combined together, take a look at below links:</p>
<ul>
<li><a href="https://stackoverflow.com/questions/61152587/istio-1-5-cors-not-working-response-to-preflight-request-doesnt-pass-access-c">Istio 1.5 cors not working - Response to preflight request doesn&#39;t pass access control check</a></li>
<li><a href="https://github.com/istio/istio/issues/16171" rel="nofollow noreferrer">https://github.com/istio/istio/issues/16171</a></li>
</ul>
<hr />
<p>There is another <a href="https://github.com/istio/istio/issues/23757" rel="nofollow noreferrer">github issue</a> about that, in this <a href="https://github.com/istio/istio/issues/23757#issuecomment-634144575" rel="nofollow noreferrer">comment</a> community member have the same issue, maybe it's worth to open a new github issue for that?</p>
<hr />
<p>Additionally there is an answer from istio dev @howardjohn</p>
<blockquote>
<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.envoyproxy.io/docs/envoy/latest/start/sandboxes/cors.html?highlight=cors" 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.sohamkamani.com/blog/2016/12/21/web-security-cors/#:%7E:text=CORS%20isn%27t%20actually%20enforced,header%20in%20all%20its%20responses" 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://github.com/istio/istio/pull/26231" rel="nofollow noreferrer">#26231</a>.</p>
</blockquote>
<hr />
<p>As I mentioned in comment worth to take a look at another community member configuration <a href="https://stackoverflow.com/questions/63313148/istio-1-6-authorizationpolicy-does-not-have-proper-response-code-if-coming-from">here</a>, as he has a working options example, but have a 403 issue with POST.</p>
<hr />
<p>Few things I would change in your virtual service</p>
<p>Use just <code>corsPolicy</code> instead of <code>corsPolicy: &amp;apiCorsPolicy</code></p>
<pre><code>corsPolicy:
</code></pre>
<p>Instead of exact you can also use regex which may do the trick for wildcards.</p>
<pre><code>allowOrigins:
- regex: '*'
</code></pre>
<p>About the <code>/</code> and <code>/api</code> paths, I think prefix is enough here, you don't need rewrite.</p>
<hr />
