CORS
Cross-origin resource sharing (CORS) is a mechanism for integrating applications. CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different domain. This is useful because complex application often reference third-party APIs and resources in their client-side code. For example, your application may use your browser to pull videos from a video platform API, use fonts from a public font library, or display weather data from a national weather database. CORS allows the client browser to check with the third-party servers if the request is authorized before any data transfers.
Why is cross-origin resource sharing important?
In the past, when internet technologies were still new, cross-site request forgery (CSRF) issues happened. These issues sent fake client requests from the victim's browser to another application.
For example, the victim logged into their bank's application. Then they were tricked into loading an external website on a new browser tab. The external website then used the victim's cookie credentials and replayed data to the bank application while pretending to be the victim. Unauthorized users then had unintended access to the bank application.
To prevent such CSRF issues, all browsers new implement the same-origin policy.
Same-Origin Policy (SOP)
Today, browsers enforce that clients can only send requests to a resource with the same origin as the client's URL. The protocol, port, and hostname of the client's URL should all match the server it request.
Cross-origin resource sharing (CORS) is an extension of the same-origin policy. You need it for authorized resource sharing with external third parties. For example:
- You need CORS when you want to pull data from external APIs that are public or authorized.
- You also need CORS if you want to allow authorized third-party access to your own server resources.
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:
- The browser adds an origin header to the request with information about current origin's protocol, host, and port
- The server checks the current origin header and responds with the requested data and an Access-Control-Allow-Origin header
- The browser sees the access control request headers and shares the returned data with the client application
Alternatively, if the server doesn't want to allow cross-origin access, it responds with an error message.
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 request
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://news.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.