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
andContent-Language
headers: Can only have values consisting of0-9
,a-z
,A-Z
, space or* - . ; , =
-
Accept
andContent-Type
headers: can't contain a CORS-unsafe header byte -
Content-Type
: It needs to have a MIME type of its parsed value of eitherapplication/x-www-form-urlencoded
ormultipart/form-data
ortext/plain
To deceive the above requirements for the default headers, you have to specify the default headers in theAccess-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 inAccess-Control-Expose-Headers
header.
Top comments (0)