CORS explained

Introduction

CORS stands for Cross-Origin Resource Sharing. 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:

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:

• Accept-Language and Content-Language headers: Can only have values consisting of 0-9, a-z, A-Z, space or * - . ; , =
• Accept and Content-Type headers: can't contain a CORS-unsafe header byte
• Content-Type: 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

  ---

  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.

The CORS-safelisted response headers include the following headers:

• Cache-Control
• Content-Language
• Content-Length
• Content-Type
• Expires
• Last-Modified
• Pragma You can extend the list of CORS-safelisted response headers by specifying the headers in Access-Control-Expose-Headers header.