When creating CORS rules for storage in Azure, it’s important to understand what each rule will enforce and what values are represented. Let’s take a closer look at what CORS rules in Azure Storage look like.
Please read the previous parts of the series before continuing with this one,
- <Cors>
- <CorsRule>
- <AllowedOrigins></AllowedOrigins>
- <AllowedMethods></AllowedMethods>
- <AllowedHeaders></AllowedHeaders>
- <ExposedHeaders></ExposedHeaders>
- <MaxAgeInSeconds></MaxAgeInSeconds>
- </CorsRule>
- <CorsRule> … </CorsRule>
- <Cors>
This is the anatomy of a set of CORS rules in Azure. There are several things that are important here. First, the representation of CORS rules is XML, not JSON, or any other representation. This is how Azure stores rules in raw form. As you will see in some of the following demos, we’ll be working directly with the XML representation of rules. Some tools will abstract this XML representation, but it’s still important to know what’s going on behind the curtain, as it were.
The second thing to point out is the root CORS element, it can contain 0 or more CORS rule elements. Each CORS rule represents a single rule. The rules are evaluated by Azure in the same order they appear in this format, so to reorder rules, you would need to manipulate the existing XML to reorder the CORS rule elements. Let’s walk through each of the rule properties in a little more detail.
Allowed Origins
- <AllowedOrigins>
- https:
- </AllowedOrigins>
AllowedOrigins property is how you’d specify the various allowed origin hostnames that can request resources. You can either enter each origin separately using a comma-delimited list, or you can simply enter the wildcard to start character to allow any origin. Also, note that Azure uses a case sensitive exact match. There is no wildcard prefix or suffix support for this property. The origin must match exactly the origin that’s coming in.
Here in the Azure portal, I’ve specified to only allow the localhost domain for CORS requests. Let’s take a look at what happens in our previous example request from our localhost URL. The image failed to load as we’d expect.
Let’s open the developer tools and take a look at the console. The error message here says the access control allow origin is missing on the response. Below the origin did not match, the CORS rule evaluated failed and Azure will respond with the HTTP 403 forbidden response.
We can even take a peek at the Network tab if we refresh, we can see the request was canceled. Specifically, Azure did respond with an HTTP 403, but we can’t even see that because the browser itself has canceled the request internally.
Allowed Methods
- <AllowedMethods>
- HEAD, GET, OPTIONS
- </AllowedMethods>
AllowedMethods property restricts what HTTP verbs are allowed on request for resources. For example, the rule only allows the HEAD, GET, and OPTIONS methods on a request. This can be a single or multiple value list, separated with commas, and the list of methods Azure supports DELETE, GET, HEAD, MERGE, POST, OPTIONS and PUT. Entering a method not on the list is not supported. Now, we recall the CORS pre-flight requests using the OPTIONS method. What would you expect to happen if we did not include OPTIONS in the AllowedMethods list?
Well, let’s take a look. Back in the portal, I’ve now made sure I specify our localhost origin as an allowed origin, but now I’ve only enabled GET requests.
In our demo example with a simple CORS image request, we can see that the request has succeeded. Remember that this constitutes a simple request, so only a GET was issued by the browser.
That’s it -- I hope you have learned how to create CORS rules for Azure Storage using AllowedOrigins and AllowedMethods properties. In the next article, we will see AllowedHeaders, ExposedHeaders, and MaxAgeInSeconds properties. Feel free to fill up the comment box below if you need any further assistance.