Welcome back to CORS Rules Concepts in Azure storage, In the previous article
, we saw how the CORS rule is represented and explained one by one detailly with demos. Here we see the remaining CORS rules with the following demos. Please read the previous parts of the series before continuing with this one,
AllowedHeaders list the custom headers that the incoming request may send. This can be a list of header names that either are exact matches, also called literals headers, or they can also be wildcard prefixed headers. For example, the snippet allows any headers that start with x-ms-meta-, and it also allows the literals x-api-key header. The value can also be a single wildcard value to allow any header. Keep in mind the limits that we talked about in the last module regarding how may prefix headers you can have.
In the portal, I’ve set a literal header value for the AllowHeaders property set to x-api-key. Let’s look at the basic CORS image demo.
Now in this example, remember that I’ve set the cross-origin attribute, so this will result in a CORS request. Would you expect the request to fail or succeed now that I’ve only allowed a specific header?
Well, let’s find out. And it succeeds. The reason is we did not initiate the request with any headers, so the outgoing request did not specify an Access-Control-Request-Headers header for Azure to evaluate.
- x-ms-meta-* , x-request-duration
The ExposedHeaders property allows you to specify what additional headers Azure will tell the browser to expose on the request. Azure will include the Access-Control-Expose-Headers response header to indicate to the browser what HTTP header is allowed to be exposed. The value can be a comma-separated list of literal or wildcard prefixed headers.
If you want to provide unrestricted access to all response headers Azure sends on responses, you could enter a single wildcard value, but I wouldn’t really recommend this. It means that any client that initiates a CORS request can read any header sent back from Azure, which could include sensitive information that could be used in malicious ways.
In general, it’s best to only allow specific headers as needed. In this example, if a CORS request came in the response Azure sends back would tell the browser that the request initiator could access any header starting with x-ms-meta-, or the literal x-request-duration header. Even if Azure sent back other headers, they would not be visible to the initiator.
I’m using that phrase “visible to the initiator” specifically because all response headers are always visible to you as a user using browser tools or by inspecting the raw HTTP response. This mechanism is only to restrict what an indicator, like a script, can access. In other words, this does not hide any response headers from the server, its just hints to the browser to restrict exposing headers to scripts or resources on the page.
In the portal, I’m now set to expose only the x-ms-request-id header, which is present on all storage requests.