Introduction
CORS-supported Azure Storage provides a few important features that we’ll explore more in-depth later. Please read the previous parts of the series before continuing with this one:
- Azure Storage CORS Concepts - Introduction - Part One
- Azure Storage CORS Concepts - CORS In The Browser - Part Two
- Azure Storage CORS Concepts - Supporting Multiple Origins And Credentials - Part Three
CORS Features in Azure Storage
-
Multiple origin support.
-
Separate rules per service.
-
Partial matching with headers.
-
Set allowed max-age, headers, and methods.
Multiple origin support
Azure providers multiple origin support by allowing you to enter origin with comma-separated values. These are per rule, and you can have multiple rules so you could have an allow list, deny list, and a wildcard rule all work together.
Separate rules per service
You can set separate rules for blob, file, queue, and table services.
Partial matching with headers
Azure allows you to partially match headers and rules using a pre-fixed header like x-ms-*.
Set allowed max-age, headers and methods
You can also set the max-age allowed headers and allowed methods of rules. There are several limitations to be aware of when using CORS with Azure Storage accounts,.
CORS Limitations in Azure Storage
-
No premium storage support.
-
5 rules per service.
-
Max of 2KB.
-
256 character limitation on header and origin names.
-
Max of 64 literal headers.
-
Max of 2 partial headers.
No premium storage support
Azure does not yet offer CORS support for the SSD-backend premium storage accounts.
5 rules per service
There’s a limit of five CORS rules for each storage service, blob, file, queue, and table.
Max of 2KB
The maximum the entire set of CORS rules can be is 2KB. This is from an API perspective. The payload to set CORS rules should not exceed 2KB. In the portal, it’s unlikely you’d reach that limit, but it is something to keep in mind for our automation demos we’ll have later on.
256 Character limitation on header and origin names
There’s a 256-character limit on header names and individual origin URLs.
Max of 64 “literal” headers”
You also can’t add more than 64“literal” headers to a CORS rule. A literal header is an exact header name like x-api-key.
Max of 2 “partial” headers
You also can’t have more than two partial headers in a rule. These are wildcard prefixed headers like x-*.
Note
Successful CORS preflight requests are billed.
It’s important to note that Azure will bill you for successful preflight requests. This means that without configuring the max-age rule, you could end up doubling costs due to the preflight request and the original request being served. Unsuccessful preflight requests are not billed, so you won’t be punished by denied requests. It would be best to configure the max-age, which I’ll explain in my next article to reduce the number of preflight request browsers we’ll do to keep costs down.
Summary
Until now, we have seen how CORS works within an Azure Storage context. Also, we have learned how the browser was the party that initiated a CORS request and the server fulfilled it. It is not something that the server can enforce by default.
We also saw how not all cross-origin requests are equal. Simple requests are not CORS-enabled by default, but you can hint to the browser through the cross-origin attribute to enable CORS. On the flip side in scripts, all cross-origin requests are CORS enabled by default. Preflighted requests are a special type of CORS request that browsers will send when certain conditions are met.
Supporting multiple origins can be done through the wildcard character or through application or server layer logic.
Finally, we have seen some key limitations of CORS rules in Azure Storage you need to be aware of when writing automation. We have enough foundation now to see all the different ways to configure CORS with Azure Storage through the portal. That’s what we’ll focus on for the rest of the article. Feel free to fill up the comment box below if you need any further assistance.