Q27: CORS Headers

[00:00:00]
>> Let's talk about CORS. What's true about the following CORS config? A preflight request is required. Only requests from https://www.thewebsite.com are allowed. Requests with cookies are allowed. The actual response is cached for 600 milliseconds. X custom header will be the only included response header. Or getPostPatchInput methods are allowed but not delete So the only right answer here is only requests from https://www.thewebsite.com are allowed.

[00:00:32]
So first let's just talk about CORS. It's always kind of annoying, but actually before we talk about CORS, let's talk about the same-origin policy. So by default you know that our browsers implement something called the same-origin policy, which prevents any cross origin requests. But that's just not how the web works, we need to fetch resources or use resources from other origins as well, otherwise you're just be stuck with your own resources the whole time.

[00:01:00]
So CORS is actually an extension of that same origin policy, but instead it allows you to do cross-origin resource sharing. So it actually allows you to do it instead of restricts it. So in this case, we're making a cross-origin request, right? We're going from website.com to api.other.com/posts, and with CORS it also adds the origin header.

[00:01:20]
So this request came from www.website.com. And the server if it has the CORS headers kind of configuration will then respond if it has CORS with the access control allow origin. And this header essentially says okay, this is fine. Responses are allowed or requests from this origin are allowed to read the resource I'm sending you.

[00:01:41]
So of course, it kinda has a checklist and a browser is like okay, does the access control allow origin match the origin of the request? And in this case it does, right? Like the origins match. So now the resource is allowed to be accessed by the browser. If it was different, like if the access control allow origin just said, okay site could access these resources, then it would have been blocked and we don't have access to these resources in the browser.

[00:02:09]
So it's important to remember that CORS is in your browsers and your user agent is not on the server, it's just a browser security feature that makes sure that when you're fetching a resource or doing anything it's from a secure origin or they allow that response to be read, does that makes sense?

[00:02:25]
So the server still processes the entire get request or the post request stuff like that. We have many other like CORS headers, right? So for example allows access control allow methods gets, in this case we are sending in get request and that is allowed by the CORS policy on the server, so that's all good.

[00:02:44]
But if we're sending a post and the control out method still gets, then that request would fail. Or if the request would still go right, but the browser would block you from accessing that resource. So then there's something called a Simple Request and a Preflighted Request. So in CORS, a simple request is any request made with get, head, and post, and it just has either accept, accept language, content language, or content type.

[00:03:09]
If the request is just that, it's called a simple request, and it doesn't require something called a preflighted request, which we'll talk about later. But if anything is not that, so like delete, put, patch, or any other of those CORS safe listed headers, then it'll be preflighted. And essentially what that means is that before sending the actual request, it'll send an options request to the server saying, hey, I'm about to send this request from this origin with this access control request, or with this method, so in this case, delete.

[00:03:39]
So it adds that to the access control request method header on the preflight at request. And then the server's probably gonna be like, well, don't even bother sending that because either my CORS configuration doesn't allow that. So don't even send the original request after sending a preflight at request, does that makes sense?

[00:03:58]
So in this case, we're sending a delete, which is not a simple request, has to be preflighted. So we first send the options request with the origin and the access control request method for delete. And then the server is like, well, it sends no content, so 204 and it sends back its CORS headers, right?

[00:04:17]
So it sends the Access-Control-Allow-Origin but then it only has the access control allow methods GET and POST not delete. So the actual delete requests will never even be sent to the server. So yeah, the origin is allowed but the method isn't. Now, when we go back to the original question, a preflight request is required.

[00:04:36]
You cannot know that from just this CORS config, it depends on the request coming in. If it's just a get request from the origin from website.com, then a preflight request isn't required, but if it's a delete, then it would. Yeah, only request from https://www.website.com are allowed? Yes, because we have the access control allow origin to have that specific domain as the allowed origin, no other origins are allowed.

[00:05:00]
Request with cookies are allowed by default. No, unless we set the access control allow credentials header on the CORS config as well. The actual response is cached for 600 milliseconds is false. The Access-Control-Max-Age that you see is just how long it caches that preflight request response that we just saw.

[00:05:19]
So it doesn't have to do that every time, we can just say, okay, you can do it once and then just cache that response for a while and that's fine. The X-Custom-Header is not the only included response header. By default, you will also just have the default response headers.

[00:05:33]
But the exposed headers just allows you to expose custom headers that aren't normally CORS safe listed. Yeah, I don't know, if you need to use any custom header, you have to explicitly expose them, otherwise the CORS records will fail. And GET, POST, PATCH and PUT methods are allowed but not DELETE.

[00:05:52]
That is false because we're allowing all methods, we have the asterisk, which just says like, yeah, allow all methods. So DELETE is also allowed.