Edge does not appear to honour Vary: Origin when caching access control headers

Issue #8047605 • Assigned to Brandon M.


Matt B.
Jun 30, 2016
This issue is public.
Found in
  • Microsoft Edge
Found in build #
Reported by 12 people

Sign in to watch or report this issue.

Steps to reproduce




Help us narrow down the issue by selecting one of the following areas: (bug reporting guidelines)

Broken Site
What is the expected behavior? (bug reporting guidelines)

We have a Cloudfront CDN distribution with the following CORS configuration:

<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">

This should allow cross origin requests from foo.cezanneondemand.com, bar.cezanneondemand.com etc, but not abc.example.com (for example). Indeed this configuration works fine for all browsers tested (Firefox, IE, Chrome, Safari) but not Edge.

On Edge, the cross origin requests are allowed from the first valid origin visited in the browser (e.g. foo.cezanneondemand.com), but then rejected with the SEC7120 error mention above when accessed from any subsequent valid origin (e.g. bar.cezanneondemand.com). The same problem occurs if the CORS configuration is set up with a separate rule per origin (so with no wildcard in the <AllowedOrigin> tags although testing with cURL shows that the headers sent by the CDN are exactly the same for both configurations.

The only configuration that does work is setting the <AllowedOrigin> value to , which does change the Access-Control-Allow-Origin header in the response to "". However this is not an option for us as it opens up our CDN to all origins, not just those we control.

Based on these steps, it looks like the CORS policy is being cached across origins despite the “Vary: Origin,Access-Control-Request-Headers,Access-Control-Request-Method” response header.

You can find the exact headers sent by our CDN with each configuration in the attachments.
Steps to reproduce the problem (include URL if applicable): (bug reporting guidelines)

Create a basic HTML page that makes an XHR request to a resource on an S3/Cloudfront CDN with a CORS rule similar to the one in the ‘expected behaviour’ section, but with a domain that you control (for the purposes of these instructions, let’s assume *.example.com).

Host your test page on two subdomains (e.g. foo.example.com and bar.example.com). If you first visit the page on foo.example.com first, then you’ll get SEC7120 errors when you subsequently visit the page on bar.example.com; conversely if you first visit the page on bar.example.com first, then you’ll get SEC7120 errors when you subsequently visit the page on for.example.com.

If you change the <AllowedOrigin> to * and wait for the changes to propagate, then the SEC7120 will stop occurring.


0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Venkat K.”

      Changed Assigned To from “Venkat K.” to “Brandon M.”

    • I am seeing this as well. Please respsond Microsoft!!!

    • One could argue, don’t cache access-control headers at all. I see a request going to the server, and the response is valid and has a correct header. Why does it keep the header from the previous subdomain?

    • Here is a reduced test case that shows that bug:


      The main page is origin "https://rawgit.com", and for the sake of another origin I’ve included an iframe which is hosted at origin “https://cdn.rawgit.com” (would not need to be an iframe, could be just another page navigated to). Both make a request to the same resource on another server. This fails in Edge, but works in IE11, Chrome, Firefox and Safari.

    • Microsoft Edge Team

      Changed Status to “Confirmed”

    • Still experiencing in build :
      Microsoft Edge 38.14393.1066.0

      Any progress ?!


    • Microsoft Edge Team

      Changed Status from “Confirmed”

    • Any known workaround except forcing CORS for all requests that could be requested with CORS in the future?

    You need to sign in to your Microsoft account to add a comment.

    Sign in