What is Cross-Origin Resource Sharing?

Cross-origin resource sharing (CORS) is like a tool that helps different apps work together. It allows a web app from one place to talk to and use things from another place. This is handy because many apps need to use stuff like pictures or information from other websites. For instance, your app might want to show videos from a video website, use fonts from a common font library, or display weather information from a national weather database. CORS makes sure that the app checks with the other websites to make sure it's okay before getting or sending any information.

Why is cross-origin resource sharing important?

A long time ago, when the internet was just starting out, there were problems called cross-site request forgery (CSRF). These problems made fake requests from a person's web browser to a different app.

Imagine someone logged into their bank account. Then, they got tricked into opening a new tab with a different website. This other website used the person's login info and sent information to the bank as if it was the person. This let unauthorized people get into the bank app without permission.

How does cross-origin resource sharing work?

In standard internet communication, your browser sends an HTTP request to the application server, receives data as an HTTP response, and displays it. In browser terminology, the current browser URL is called the current origin and the third-party URL is cross-origin.

When you make a cross-origin request, this is the request-response process:

1. The browser adds an origin header to the request with information about the current origin's protocol, host, and port
2. The server checks the current origin header and responds with the requested data and an Access-Control-Allow-Origin header
3. The browser sees the access control request headers and shares the returned data with the client application.
4. Alternatively, if the server doesn’t want to allow cross-origin access, it responds with an error message.

Cross-origin resource sharing example

For example, consider a site called https://blogs.example.com. This site wants to access resources from an API at weather-api.com.

Developers at https://weather-api.com first configure the cross-origin resource sharing (CORS) headers on their server by adding blogs.example.com to the allowed origins list. They do this by adding the below line to their server configuration file.

Access-Control-Allow-Origin: https://blogs.example.com

Once CORS access is configured, blogs.example.com can request resources from weather-api.com. For every request, weather-api.com will respond with Access-Control-Allow-Credentials : "true." The browser then knows the communication is authorized and permits cross-origin access.

If you want grant access to multiple origins, use a comma-separated list or wildcard characters like * that grant access to everyone.

What is a CORS preflight request?

In HTTP, request methods are the data operations the client wants the server to perform. Common HTTP methods include GET, POST, PUT, and DELETE.

In a regular cross-origin resource sharing (CORS) interaction, the browser sends the request and access control headers at the same time. These are usually GET data requests and are considered low-risk.

However, some HTTP requests are considered complex and require server confirmation before the actual request is sent. The preapproval process is called preflight request.

Complex cross-origin requests

Cross-origin requests are complex if they use any of the following:

• Methods other than GET, POST, or HEAD
• Headers other than Accept-Language, Accept, or Content-Language
• Content-Type headers other than multipart/form-data, application/x-www-form-urlencoded, or text/plain

So, for example, requests to delete or modify existing data are considered complex.

How preflight requests work

Browsers create preflight requests if they are needed. It's an OPTIONS request like the following one.

OPTIONS /data HTTP/1.1

Origin: https://example.com

Access-Control-Request-Method: DELETE

The browser sends the preflight request before the actual request message. The server must respond to the preflight request with information about the cross-origin requests the server’s willing to accept from the client URL. The server response headers must include the following:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

An example server response is given below.

HTTP/1.1 200 OK

Access-Control-Allow-Headers: Content-Type

Access-Control-Allow-Origin: https://blogs.example.com

Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

The preflight response sometimes includes an additional Access-Control-Max-Age header. This metric specifies the duration (in seconds) for the browser to cache preflight results in the browser. Caching allows the browser to send several complex requests between preflight requests. It doesn’t have to send another preflight request until the time specified by max-age elapses.