CORS explained
Tags: devops, webdev, beginners
Published: 2021-08-25 13:57:09

## Introduction
CORS stands for **C**ross-**O**rigin **R**esource **S**haring. It is a system which consists of transmitting HTTP headers. It determines whether browsers block frontend JavaScript code from accesing cross-origin resources. The Same origin security policy forbids cross origin access to resources. A cross origin request is a request to another url. CORS gives web servers the ability to allow frontent JavaScript code in the browsers to access their resources.

## Overview
When you access a resource on the same web domain using frontend JavaScript code, you can access it with a 200 status code. When you try to access a resource on another domain using frontent JavaScript code, it might return you a CORS error, depending on the configuration of the web server. The browser doesn't allow frontend JavaScript code to access cross-origin resources(resources on another domain) unless the web server has allowed it to. You can allow cross origin requests on your web server by specifying the CORS origin as `*` or the specific url you want to allow the Cross origin requests from.

## Preflighting requests
Non-standard HTTP headers like `PUT`, `PATCH` and `DELETE` need to be preflighted. It is just a security check to ensure that the request is safe to go to the server. The browser automatically knows when to preflight a request. When it preflights a request, it includes the `OPTIONS` Http verb containing the origin name in the headers. The web server would then respond that it does or doesnt allow the request. The above method is inefficient in some cases, another technique to handle non-standard HTTP headers is as follows:<br>
The web server can respond with a max age header(`Access-Control-Max-Age: 3600`) allowing the browser to cache a preflight for a certain amount of time. The request will be cached so that no discrepancy is caused in the server and the database (discussed more about this in [caches]https://dev.to/hamiecod/caching-explained-23jc))

## CORS Headers
### CORS-safelisted request header
`Accept`, `Accept-Language`, `Content-Language` and `Content-Type` are CORS-safelisted request headers. When containing only these headers, a request doesn't need to send a preflight request to the web server in the context of CORS. More headers can be safelisted using the `Access-Control-Allow-Headers` header. The headers have to follow certain requirements to be CORS safelisted headers. The requirements are:
- <u>`Accept-Language` and `Content-Language` headers</u>: Can only have values consisting of `0-9`, `a-z`, `A-Z`, space or `* - . ; , =`
- <u>`Accept` and `Content-Type` headers</u>: can't contain a CORS-unsafe header byte
- <U>`Content-Type`</u>: It needs to have a MIME type of its parsed value of either `application/x-www-form-urlencoded` or `multipart/form-data` or `text/plain`<br><hr>
To deceive the above requirements for the default headers, you have to specify the default headers in the `Access-Control-Allow-Headers` header.

### CORS-safelisted response header
It is an HTTP header in a CORS response, it depicts that the response is considered safe to expose to client scripts. Only safelisted response headers are made avaiilable to web pages. <br>
The CORS-safelisted response headers include the following headers:
- `Cache-Control`
- `Content-Language` 
- `Content-Length`
- `Content-Type`
- `Expires`
- `Last-Modified`
- `Pragma`
<br><br>
You can extend the list of CORS-safelisted response headers by specifying the headers in `Access-Control-Expose-Headers` header.