CORS-supported Azure Storage provides a few important features that we’ll explore the more in depth later here. Please read the previous parts of the series before continuing with this one,
CORS Features in Azure Storage:
- Multiple origin support.
- Separate rules per service.
- Partial matching with headers.
- Set allowed max age, headers and methods.
1. 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.
2. Separate rules per service:
You can set separate rules for blob, file, queue, and table services.
3. Partial matching with headers:
Azure allows you to partially match headers and rules using a pre-fixed header like x-ms-*.
4. 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, though.
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
1. No premium storage support:
First, Azure does not yet offer CORS support for the SSD-backend premium storage accounts.
2. 5 rules per service:
There’s a limit of five CORS rules for each storage service, blob, file, queue, and table.
3. 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.
4. 256 Character limitation on header and origin names:
There’s a 256-character limit on header names and individual origin URLs.
5. 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.
6. 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 origin 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 amount of preflight request browsers we’ll do to keep costs down.
Till now we have seen how CORS works within an Azure Storage context. Importantly, 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.