Introduction
In this article, you will see how the CORS supports multips origins and requests with credentials. Please read the previous parts of the series before continuing with this one.
Supporting Multiple Origins and Credentials
In the previous
article, we saw how specifying an origin in the allow origin header restricted to a single origin, but you can also use the wildcard character, an asterisk (*), to allow all. This is saying allow any origin to request this resource. This is important to realize as many resources suggest using the wildcard origin, but this negates a lot of the security benefits CORS gets you. No problem, you might say, we can just return a comma-separated list of known good origins, can’t we? Unfortunately, no. The origin has to exactly match the origin the browser sends, which means you can’t return multiple origins on the header.
What we can do to only allow specific origins?
We actually need to introduce logic in our server to inspect the incoming origin header and respond with the same origin if it matches an origin in our allow list or to not respond with the header, which effectively disallows the request. We can do this in many ways, including a load balancer, web server response, rewrite rules, or application framework code.
Since we are seeing about configuring CORS with Azure Storage, I’m happy to tell you that Azure makes it easy to provide a comma-separated list of allowed origins when you configure CORS. So in our case, we’re all set.
Browsers, by default, treat CORS requests as anonymous, meaning they don’t send credential information in the request. You can opt into sending credentials with a CORS request, in which case the browser will send cookies subject to the same normal cookie restrictions and HTTP authentication information like the authorization header.
Request with Credentials
Doing this requires the server to always respond with a non-wildcard origin for the Access-Control-Allow-Origin header and to include an Access-Control-Allow-Credential
Header set to true. If it responds with a wildcard, the browser fails the request.
It’s extremely important to understand the CORS is not an authentication mechanism. This entire process happened in our client browser. That means that the server really can only suggest a CORS policy, and it’s up to the client to respect the policy. Even if a server returns the CORS header, the browser will not treat the request as a CORS enabled request with the origin header. Both the browser and server need to understand they are in a CORS context for the rule evaluations to take effect. This means while modern browsers used by our end user will respect CORS, a malicious user could just use their own script to download resources with reckless abandon because you can bet that they don’t care about your precious CORS policy. So it’s up to the server to leverage other mechanisms like authentication and anti-cross-site request forgery tactics to mitigate malicious clients.
That’s it, I hope you have learned how the CORS supports multips origins and request with credentials. In the next article, we will see using CORS with Azure Storage. Feel free to fill up the comment box below if you need any further assistance.